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

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



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.

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



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 *
Junit-devel mailing list