[TIP] cleanUp for unittest

Michael Foord fuzzyman at voidspace.org.uk
Fri Apr 3 12:21:47 PDT 2009

John Arbash Meinel wrote:
> 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.)

Here's the bzr implementation for reference:



> 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.
> John
> =:->
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> KK8An1uY8lJ7NWiShJcikzANlwEBMWk2
> =afKr


More information about the testing-in-python mailing list