[TIP] cleanUp for unittest

Olemis Lang olemis at gmail.com
Fri Apr 3 12:51:53 PDT 2009


On Fri, Apr 3, 2009 at 2:15 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
>
> 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.
>

I agree 100 % with this ... write a unittest.TestCase descendant and
do it that way ... ;)


--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:



-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?



More information about the testing-in-python mailing list