This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author michael.foord
Recipients gregory.p.smith, jml, kumar303, michael.foord, ngie, pitrou, rbcollins, vdupras
Date 2009-04-26.21:17:00
SpamBayes Score 3.3270303e-06
Marked as misclassified No
Message-id <>
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) -> 

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 

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.
Date User Action Args
2009-04-26 21:17:10michael.foordsetrecipients: + michael.foord, gregory.p.smith, pitrou, rbcollins, vdupras, jml, kumar303, ngie
2009-04-26 21:17:10michael.foordsetmessageid: <>
2009-04-26 21:17:08michael.foordlinkissue5679 messages
2009-04-26 21:17:05michael.foordcreate