[TIP] cleanUp for unittest

jason pellerin jpellerin at gmail.com
Fri Apr 3 12:07:46 PDT 2009

> It doesn't make any other use cases harder because you simply don't have to
> use it - nor is it difficult to explain (except evidently the rationale).

I guess we just disagree. For me it's self-evidently weird to have an
api that consists entirely of subclassing TestCase, except for this
one part that operates in a totally different way.

>> If you want the list of stuff for cleanup in cleanUp and cleanUp is
>> just a method, you can do it like this:
>> def setUp(self):
>>      self._cleanUp = []
>>      self.db = ScratchDb()
>>      self.db.setup()
>>      self._cleanUp.append(self.db.teardown)
>>      self.tmp = TempIO()
>>      self._cleanUp.append(self.tmp.destroy)
>> def cleanUp(self):
>>      for func in self._cleanUp:
>>            func()
> So where do you put that - in the test, in tearDown?

I haven't made myself clear. I'm not against the idea of adding an
unconditionally called cleanUp method and didn't mean to suggest that
I was. Apologies for the confusion.

I *am* against the idea of including a concrete implementation of that
method in the core of unittest, for the reasons I outlined.

> Should TempIO() fail (for whatever reason), then neither the test nor
> tearDown would be executed and the cleanup not done. How do you propose to
> solve that?

So hopefully I'm being more clear now... +1 "finally: cleanUp()", -1
"Include a particular implementation of cleaning things up in


More information about the testing-in-python mailing list