Author michael.foord
Recipients gregory.p.smith, jml, kumar303, michael.foord, pitrou, rbcollins, vdupras, yaneurabeya
Date 2009-04-26.21:17:00
SpamBayes Score 3.32703e-06
Marked as misclassified No
Message-id <1240780630.03.0.154755703185.issue5679@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2009-04-26 21:17:10michael.foordsetrecipients: + michael.foord, gregory.p.smith, pitrou, rbcollins, vdupras, jml, kumar303, yaneurabeya
2009-04-26 21:17:10michael.foordsetmessageid: <1240780630.03.0.154755703185.issue5679@psf.upfronthosting.co.za>
2009-04-26 21:17:08michael.foordlinkissue5679 messages
2009-04-26 21:17:05michael.foordcreate