[TIP] cleanUp for unittest
robertc at robertcollins.net
Fri Apr 3 15:27:03 PDT 2009
On Fri, 2009-04-03 at 15:10 -0400, Doug Philips wrote:
> 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
> 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...
As already mentioned jml's testtools has a addCleanup inspired by bzr
and trial. I know he'd like to see that in the stdlib as would I
(testtools is intended as a best-practice collection for unittest
improvements, a unittest-next if you will).
I'd be happy to extract a patch from testtools for addCleanup(cleanup,
*args, **kwargs) if this approach is acceptable.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.idyll.org/pipermail/testing-in-python/attachments/20090404/7b8b93f1/attachment.pgp
More information about the testing-in-python