Re: [Junit-devel] tearDown() not called if setUp() fails - definitely a bug (IMO)

[Stephen K. <Ste...@or...>]

Does not look like it - I've updated to version 1.18.2.2 (kbeck on 2 
June 05):

public void runBare() throws *Throwable *{
        Throwable exception= null;
      *  setUp();*
        try {
            runTest();
        } catch (Throwable running) {
            exception= running;
        }
        *finally *{
            try {
                *tearDown*();
            } catch (Throwable tearingDown) {
                if (exception == null) exception= tearingDown;
            }
        }
        if (exception != null) throw exception;
    }

Cheers

Stephen

Dean Hiller wrote:

> I believe this fix is in the head of CVS.  It is just not released.  
> You can build your own version of JUnit from CVS which has the fix.
> dean
>
> Stephen Kestle wrote:
>
>> This has been partially covered before, but I think the logic was 
>> inadequate.  In summary, Dean Hiller had a problem where his setUp() 
>> was failing:
>>
>>> I notice the unit test in 
>>> junit.tests.framework.TestCaseTest.testTearDownSetupFails() 
>>> specifically is written to show that an Exception in setUp() does 
>>> not call tearDown().
>>>
>>> Is there a reason for this?
>>
>>
>>
>> Kent Beck replied with:
>>
>>> Thank you for submitting your patch. The current behavior is 
>>> deliberate.
>>> My reasoning for the current behavior is that if setUp() fail, then 
>>> tearDown() is useless. SetUp() should never fail. If it does, the 
>>> whole premise of the test is false. Do you have concrete examples 
>>> where tearDown() would be useful even if setUp() fail?
>>
>>
>>
>> Dean Hiller then explained about his database problem to ensure 
>> consistency.  We have the same problem, and I think that Kent's 
>> position is a bit short-sighted.
>>
>> To back up my claim, I searched for what tearDown() is meant for.  It 
>> surprised me that it was not used in any of the "test infected" or 
>> "JUnit Cooks tour", or even the "Cookbook" - it is obviously intended 
>> for advanced usage.  In the Cookbook however, it states:
>>
>> "Override tearDown 
>> <http://junit.sourceforge.net/javadoc/junit/framework/TestCase.html#tearDown%28%29>() 
>> to release any permanent resources you allocated in setUp."
>>
>> The problem here is that if you are allocating permanent resources in 
>> setUp, you generally have absolutely no guarantee that they will be 
>> created correctly or without exception.  Therefore, you cannot assume 
>> that setUp() will not fail.
>>
>> Furthermore, since setUp() is almost always enough for a [unit] test, 
>> tearDown() should be considered advanced usage, and there will be no 
>> ill side-effects of having it run in 99% of test cases.  The tests 
>> that the code change will affect will probably want it to be the case 
>> anyhow.
>>
>> Essentially, for our database tests, our fixture must ensure that 
>> there are certain records that our tested (persistence) objects are 
>> able to access correctly.
>>
>> Please fix this - we can hack around it for the mo, but it's pretty 
>> dumb.
>>
>> Cheers
>>
>> Stephen
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
>> Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing 
>> & QA
>> Security * Process Improvement & Measurement * 
>> http://www.sqe.com/bsce5sf
>> _______________________________________________
>> Junit-devel mailing list
>> Jun...@li...
>> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>
>