Am 22.01.2012 18:18, schrieb Christian Grobmeier:
Benedikt,
not sure if got you right. But isn't this basically what JUnit provides with:
@Test(expected = NullPointerException.class)
No it isn't. As far as I know, your test will pass, when the first
NullPointerException is thrown (this also applies to @Rule
ExpectedException). If you have a method that takes two arguments that
are not nullable and you write:
@Test(expected = NullPointerException.class)
public void testMyMethod(){
// this will throw NPE
myObject.myMethod(null, someParam)
// test passes, because NPE was thrown, execution ends here
// this will never be executed
myObject.myMethod(someParam, null)
}
So I guess, it is a matter of taste. You could have a tone of one line
test methods or you can test all failure cases for one method in one
test method by wrapping method calls.
The earlier isn't that bad, now that I think about it, but it will lead
to long test method names:
public void testMyMethodNullInt
public void testMyMethodIntNull
public void testMyMethodNullNull
The benefit of this is, that you know exactly what went wrong at first
glance. The drawback is, that we have spread one concern (for example
testing null parameters on one method) across several test methods.
I think I like to have all null argument combinations in test method.
But as I said, it's certainly a matter of taste.
bye
Benedikt
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
