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 kumar303
Recipients exarkun, kumar303, ngie, purcell, rhettinger
Date 2009-03-23.21:13:32
SpamBayes Score 6.6746614e-10
Marked as misclassified No
Message-id <>
fwiw, changing tearDown() so that it executes unconditionally will break
a countless number of test suites.  No test suite since the dawn of
unittest has been designed to tearDown() what may not have been setUp()

in other words, this is how [in my experience] setUp and tearDown are
typically used together.  Imageine this error in setUp() :

def setUp(self):
    self.tmp_io = TempIO() # raise NameError("no such name TempIO")
    self.db = DataBase()

def tearDown(self):

With the change, you would need messy code like:

def tearDown(self):
    if hasattr(self, 'tmp_io'):
    if hasattar(self, 'db'):

This is just a simple example; things would get complicated fast.

I think addCleanup() is a good idea though.  Or what about a new hook
that would act like tearDown() but execute unconditionally. 
alwaysTearDown() ?  (I'm bad with names.)  Using a different hook would
solve the problem of porting test suites to this new paradigm.  But
besides that there are alternatives for doing cleanup.  I.E. if setUp()
in a class fails, then teardown_module() will still be called.
Date User Action Args
2009-03-23 21:13:37kumar303setrecipients: + kumar303, rhettinger, purcell, exarkun, ngie
2009-03-23 21:13:37kumar303setmessageid: <>
2009-03-23 21:13:33kumar303linkissue5538 messages
2009-03-23 21:13:32kumar303create