[TIP] cleanUp for unittest

[Michael Foord]

John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.)
>
>   

Adding via a method is fine by me - and as mentioned more in line with 
the rest of the unittest API.

So two Python test frameworks provide this - the frameworks used by bzr 
and by Twisted.

Michael

> 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
> =:->
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAknWYG0ACgkQJdeBCYSNAAMt5QCeOKrK+tSFuZ6T6Ku8O8hZXbZT
> KK8An1uY8lJ7NWiShJcikzANlwEBMWk2
> =afKr
> -----END PGP SIGNATURE-----
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog