[TIP] cleanUp for unittest

John Arbash Meinel john at arbash-meinel.com
Fri Apr 3 12:15:57 PDT 2009

Hash: SHA1


> I haven't made myself clear. I'm not against the idea of adding an
> unconditionally called cleanUp method and didn't mean to suggest that
> I was. Apologies for the confusion.
> I *am* against the idea of including a concrete implementation of that
> method in the core of unittest, for the reasons I outlined.
>> Should TempIO() fail (for whatever reason), then neither the test nor
>> tearDown would be executed and the cleanup not done. How do you propose to
>> solve that?
> So hopefully I'm being more clear now... +1 "finally: cleanUp()", -1
> "Include a particular implementation of cleaning things up in
> unittest.TestCase".
> JP

Just to mention that the bzr's codebase uses "self.addCleanup(callable,
*args, **kwargs)" which happens to add the callable to a list, which
will then be accessed in LIFO order. (The same as doing stuff with
atexit(), etc.)

It makes for *much* cleaner tests than the equivalent try/finally
everywhere. Imagine allocating 5 objects that should be resolved, and
you end up with some ugly nesting, just to get your finally in. (Or you
end up writing your own list and doing finally.

The reason it should happen unconditionally, is the same as try/finally.
Initialize something, and make sure it is cleaned up. Whether that was
initialized inside setUp() but something else failed (think child
classes, that call super().setUp() but then fail afterwards).

Yes, you can do it with a simple cleanUp() function, and define your own
custom list for your own custom test hierarchy (bzr already does this to
provide addCleanup). It is just a nice way of allocating some state, and
making sure it is properly removed.
setUp/tearDown start to break down when you get into larger heirarchies
of classes. You really want to just run the tearDown()s that correspond
to the setUp()s that succeeded. Appending the cleanup function to a list
to indicate that the resource was properly acquired is a fairly clean
way to do that.


Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the testing-in-python mailing list