[TIP] cleanUp for unittest
fuzzyman at voidspace.org.uk
Fri Apr 3 11:52:08 PDT 2009
jason pellerin wrote:
> On Fri, Apr 3, 2009 at 1:53 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>> Kumar McMillan wrote:
>>> On Fri, Apr 3, 2009 at 12:16 PM, Michael Foord
>>>>> Doesn't matter to me, but I'm wondering... why a list of functions?
> Taking Michael's version of Kumar's example:
>> Yes - precisely; except in this particular example you would actually do:
>> def setUp(self):
>> self.db = ScratchDb()
>> self.tmp = TempIO()
> This is why I don't like the list of funcs: it's engineered to support
> a particular use case that is not universal, and by making that case
> *very* slightly easier, we make handling all other use cases more
> complex, and make the api harder to explain.
Hmm... I disagree. I think most resource cleanup and deallocation can
usually be expressed as a callable. What makes you think it is for a
particular use case.
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).
> 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.tmp = TempIO()
> def cleanUp(self):
> for func in self._cleanUp:
So where do you put that - in the test, in tearDown?
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?
> IMO there's no reason to bake that pattern into unittest. Keep the core simple.
More information about the testing-in-python