[TIP] always call teardownX even if setupX fails?

holger krekel holger at merlinux.eu
Fri Jan 22 15:43:01 PST 2010


Hi all, (cross-post, beware)

i'd appreciate some feedback regarding a decision related to this issue: 
http://bitbucket.org/hpk42/py-trunk/issue/78/
where Jeff Stearns suggests to call teardown_module in any case. 

To summarize here, please consider this:

    def setup_module(mod):
        ...

    def teardown_module(mod):
        ...

Currently teardown_module will not be called if setup_module raises
an error.  This is consistent with how nosetests and unittest.py behave
(although unitttest doesn't yet have setup_module/class, but it has
setUp/tearDown).

For py.test we could easily change it such that teardown_module is called 
independently if the call to setup_module succeeded.  The same would be 
true for setup_class/teardown_class and setup_method/teardown_method pairs.  
The rationale behind this is that setup_XYZ may set up several resources
and fail somewhere in between.  Not calling teardown_XYZ leaves 
resources unfinalized, potentially causing test setup failures in other test
modules (this is what happend to Jeff). 

Do you think it would actually hurt to call teardown in any case? 
That might cause another error of course - with py.test you would both: 

    http://paste.pocoo.org/show/168612

Doesn't look like a blocker to me at the moment.  What do you think? 
Any objections or recommendations?  Do you regard consistency a blocker? 

Note that the whole issue is not a problem with funcargs and recent unittest: 
you usually set up exactly one funcarg in a factory and if that fails 
there usually is no reason to call teardown.  And if a function gets 
several funcargs, each successful funcarg setup will have a guaranteed call
to the finalizer even if different funcarg factory calls fail.  Moreover, 
you can always use "addfinalizer()" in a factory (similar to the recent unittest 
addition addCleanup()) which will trigger an unconditionally teardown. 

cheers,
(feel free to leave out one of the cross-posted mailing lists),
holger

-- 



More information about the testing-in-python mailing list