[TIP] cleanUp for unittest

Laura Creighton lac at openend.se
Fri Apr 3 19:14:01 PDT 2009

In a message of Fri, 03 Apr 2009 20:48:54 CDT, John Arbash Meinel writes:
>Hash: SHA1
>Douglas Philips wrote:
>> On or about 2009 Apr 3, at 6:27 PM, Robert Collins indited:
>>> I'd like to note that having it as a method gives the opportunity to  
>>> do
>>> different things in subclasses and that can be useful (and it also
>>> allows for better encapsulation etc.
>>> Anyhow, my main point: Unless someone says 'don't do it' I'll put a
>>> patch up for unittest in the patch tracker to add this.
>> Still no answer to the question: What is the purpose of tearDown once  
>> this is added?
>> When should I put code into tearDown (if at all) once this is available
>> -Doug
>With addCleanup I almost never use tearDown. I don't see a specific need
>for it, other than for people used to a specific xUnit coding style.

I think that the whole idea of having tearDown only run if setUp ran
successfully was based on the idea that leaving crud around in your
filesystem (because setUp() manages to create some things before 
dying an unseemly death) was preferable to having to write tearDown
in such a way that it was guaranteed to always be able to run (even
when setUp couldn't).  Or maybe it was 'calling tearDown unconditionally
wastes a whole lot of time when it is not needed because setUp wasn't
called'.  Whatever the motivation, it looks like misdesign right now,
because more people want an unconditionallyTearDownEverything than
something that only runs when setUp succeeds.

Which may make unconditionallyTearDown a better name than 'cleanup'.
or maybe onExit.  

Are there other reasons why you would want a tearDown than only runs when
setUp runs successfully that I haven't been able to think of?


More information about the testing-in-python mailing list