[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