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 <1237842817.1.0.0183421165188.issue5538@psf.upfronthosting.co.za>
In-reply-to
Content
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()
correctly.

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):
    self.tmp_io.destroy()
    self.db.destroy()

With the change, you would need messy code like:

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

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.
History
Date User Action Args
2009-03-23 21:13:37kumar303setrecipients: + kumar303, rhettinger, purcell, exarkun, ngie
2009-03-23 21:13:37kumar303setmessageid: <1237842817.1.0.0183421165188.issue5538@psf.upfronthosting.co.za>
2009-03-23 21:13:33kumar303linkissue5538 messages
2009-03-23 21:13:32kumar303create