Benedikt,
not sure if got you right. But isn't this basically what JUnit provides with:
@Test(expected = NullPointerException.class)
Cheers
Christian
On Sun, Jan 22, 2012 at 6:11 PM, Benedikt Ritter
<b...@systemoutprintln.de> wrote:
> Hi,
>
> while I was working on the unit tests, I had to write several try catch
> blocks in order to get all the failure cases for one methods tested in one
> test method. I think those could be wrapped into some class, lets call it
> ExpectedFailure.
> ExpectedFailure is abstract and clients have to implement the abstract
> method thisMustFail(). The method is called from ExpectedFailure's
> constructor and is wrapped inside a try catch block. If no Excpetion is
> thrown during execution of thisMustFail(), a new AssertionError will be
> thrown. So instead of:
>
> @Test
> public void multipleFailuresExpceted()
> try {
> // do something that should throw an exception
> myObject.myMethod(null, someParameter);
> fail("Exception was not thrown!")
> }
> catch (NullPointerException e)
> {
> // we are happy because we got the exception we expected!
> }
>
> try {
> // do something that should throw an exception
> myObject.myMethod(someParamater, null);
> fail("Exception was not thrown!")
> }
> catch (NullPointerException e)
> {
> // we are happy because we got the exception we expected!
> }
>
> // etc we would now test the null, null case... omitted in this example
> }
>
> we can write the following:
>
> @Test
> public void multipleFailuresExpceted() {
>
> new ExpectedFailure(NullPointerException.class) {
>
> @Override
> void thisMustFail(){
> myObject.myMethod(null, someParameter);
> }
> }
>
> new ExpectedFailure(NullPointerException.class) {
>
> @Override
> void thisMustFail(){
> myObject.myMethod(someParameter, null);
> }
> }
>
> // null, null case omitted in this example
> }
>
> As you can see there are not that many lines, we can save with
> ExpectedFailure. But with code completion, you can really benefit from it.
> Also, I think it is better to have a class for wrapping those try catch
> blocks, instead of having all that in your test methods. ExpectedFailure
> helps you to focus on testing instead of catching your expected exceptions
> the right way.
>
> If you like the idea, you can browse my github repo:
> http://github.com/britter/sandbox/tree/master/util-test
> ExpectedFailure is located under src/main. I also implemented a unit test
> under src/test, if you want to see some more examples.
> I would like to contribute ExpectedFailure, if you think it is beneficial
> for BeanUtils2.
>
> regards
> Benedikt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
