[TIP] cleanUp for unittest

Doug Philips dgou at mac.com
Fri Apr 3 12:10:33 PDT 2009

 Wow, this has been a busy thread.

If I can recap to see if I understand:
a) Sometimes setUp needs to allocate resources. If setUp fails, those resources need to be processed/cleaned-up.
b) The current unittest "contract" states that if setUp fails, tearDown is not run.
c) Changing 'b' would break a lot of existing code.
d) A new mechanism is needed since handling this outside the framework involves lots of duplicate coding by users, coding that is pretty well understood and considered rather "common" (as well as annoying, boiler-plate, etc).

My personal use of unittest and the style I try to get my coworkers to use is:
i) Things done in setUp should be cleaned up in tearDown.
ii) tearDown should not use/touch/know about anything done in tests, only what is done in setUp.

We're lucky in that most of our tests don't have complex resources in setUp, and the few which do aren't severely impacted by try/finally noise.

My question is, if some kind of unconditional cleanup method/list is added to the stdlib's unittest, doesn't that effectively deprecate tearDown? Or at least lead to confusion about what should be in tearDown and what should be in the cleanUp? Picking the wrong one would have nasty surprises...


More information about the testing-in-python mailing list