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.
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.
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
>
--
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
