Am 22.01.2012 18:45, schrieb Christian Grobmeier:
On Sun, Jan 22, 2012 at 6:38 PM, Benedikt Ritter
<b...@systemoutprintln.de> wrote:
Am 22.01.2012 18:18, schrieb Christian Grobmeier:
@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:
...
The earlier isn't that bad, now that I think about it, but it will lead to
long test method names:
...
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.
OK got your intention now. As you said, it is a matter of taste. My
taste usually is too keep everything as simple and possible. My
argument is, that @Test(...) can be understood be everybody who never
dealt with the code. Using your approach (which has benefits honestly)
one must first read whats around the thisMustFail().
Let us hear what others think. I cannot say that we have a
commons-wide policy on this. Some of our test code is really complex.
You're right, I should really try to make it less complex and more
readable... Thanks for the suggestion!
If the other bu2 guys think this is looks good for them i will not
oppose, even when I would prefer the annotation base variant.
Please don't stop with suggestions like this, they are very valuable
to revisit old grown processes and help us modernize commons.
No worries I'll do that and thanks for the motivation ;-)
Regards
Benedikt
Cheers
Christan
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
