[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
unittest.TestCase".
JP
More information about the testing-in-python
mailing list