Michael Foord <mich...@voidspace.org.uk> added the comment: Updated patch with docs. My intention is to apply this in the next couple of days.
I've settled on calling doCleanups *after* tearDown. The issues and reasoning explained below. One point of view concerns using addCleanups with existing tests. If the setUp allocates resources that are deallocated by tearDown, the natural LIFO pattern would seem to be setUp -> tests that create cleanup functions -> do cleanups (which may use resources allocated by setUp) -> tearDown. This pattern doesn't allow tearDown to create cleanup functions and doesn't permit setUp to create cleanup functions if tearDown need to access those resources (unless tearDown itself becomes one big cleanup function). If you look at the situation with new tests then it is perfectly natural for setUp, tests and tearDown to all create cleanup functions. The natural LIFO order is for cleanups to be run after tearDown. The solution I've opted for is to make doCleanups public. If you are adding the use of cleanups to old tests and need the cleanup functions run before tearDown then you are free to decorate the test with a function that calls doCleanups on success or failure. This takes into account the experience of those already using test frameworks that provide this mechanism. ---------- Added file: http://bugs.python.org/file13791/unittest-cleanup.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5679> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com