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 -- _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev