On 2 October 2010 15:08, Phil Steitz <phil.ste...@gmail.com> wrote:
> On 10/1/10 10:52 AM, Luc Maisonobe wrote:
>>
>> Le 01/10/2010 16:34, Gilles Sadowski a écrit :
>>>
>>> On Fri, Oct 01, 2010 at 03:17:58PM +0100, sebb wrote:
>>>>
>>>> There are quite a few test cases that have code like:
>>>>
>>>> public void testSomething(){
>>>>     try {
>>>>       something();
>>>>       fail("an exception should have been caught");
>>>>     } catch (EstimationException ee) {
>>>>       // expected behavior
>>>>     } catch (Exception e) {
>>>>       fail("wrong exception type caught");
>>>>     }
>>>> }
>>>>
>>>> This is unnecessary code; worse, the actual Exception is lost.
>>>>
>>>> I propose to fix these by converting them to:
>>>>
>>>> public void testSomething() throws Exception {
>>>>     try {
>>>>       something();
>>>>       fail("Expecting EstimationException ");
>>>>     } catch (EstimationException ee) {
>>>>       // expected behavior
>>>> }
>>>>
>>>> Any objections?
>>>
>>> Shouldn't we move to JUnit 4, i.e. using
>>> ---CUT---
>>>     @Test(expected=EstimationException.class)
>>>     public void testSomething() {
>>>         something();
>>>     }
>>> ---CUT---
>>
>> I agree JUnit 4 is the way to go here. We already have some JUnit 4
>> tests, we simply did not change everything when we switched to Java 5
>> and change the tests slowly.
>>
>> This is a good opportunity for these tests, so +1 for the switch here.
>>
>
> I am personally not in love with using annotations in test code, but that
> train has left the station, so +0 if someone else wants to do the boring
> work to change everything.  Please be careful though not to lose sensitivity
> in the tests.

+1.

> +1 for sebb's original suggestion - the exception should not be lost.

I've done that already ...

> Phil
>>
>> Luc
>>
>>>
>>> [Of course, this would force to split the test methods that currently
>>> contain multiple statements that can throw an exception.]
>>>
>>>
>>> Gilles
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to