[Python-ideas] Test Class setup and teardown in unittest

Holger Krekel holger.krekel at gmail.com
Thu Jan 21 20:52:44 CET 2010

On Thu, Jan 21, 2010 at 8:12 PM, Brett Cannon <brett at python.org> wrote:
> On Wed, Jan 20, 2010 at 16:38, Mark Roddy <markroddy at gmail.com> wrote:
>> Earlier this week on the Testing In Python list, there was a
>> discussion on how to execute a setup and/or teardown for a single test
>> class instead of for each test fixture on the class (see the 'setUp
>> and tearDown behavior' thread).  I have had to deal with situation
>> myself before, and I am obviously not the only one (since I did not
>> initiate the thread).  As such I'd like to propose adding a class
>> level setup and tear down method the unittest TestCase class.
> Maybe I'm missing something, but why can't you simply use __init__ and
> __del__ for this purpose?

Test resource finalization needs strict semantics and predictable
timing i'd say - and at least '__del__' doesn't provide that on some
python interpreters.  Moreover, unitttest (as well as py.test and
other test runners) instantiate fresh instances for a test method exec
to prevent hidden dependencies between tests.


> -Brett
>> Rationale:
>> Test cases can at times require the setup of expensive resources.
>> This is often the case when implementing integration testing.  Having
>> to perform this setup for each fixture can prohibited for large number
>> of fixtures and/or for resources that are expensive to setup.  For
>> example, I have several hundred integration tests that hit a live
>> database.  If I create the connection object for each fixture, most of
>> the tests fail due to the maximum connection limit being reached.  As
>> a work around, I create a connection object once for each test case.
>> Without such functionality built in, the common idiom runs along these
>> lines:
>> class MyTest(TestCase):
>>    def setUp(self):
>>        if not self.ClassIsSetup:
>>            self.setupClass()
>>            self.ClassIsSetup=True
>> While this achieves the desired functionality, it is unclear due to
>> conditional setup code and is also error prone as the same code
>> segment would need to appear in every TestCase requiring the
>> functionality.  Having a class wide setup and teardown function that
>> implementers of test cases can override would make the code/intent
>> more clear and alleviate the need to implement test case functionality
>> when the user should be focusing on writing tests.
>> I emailed Michael Foord about some of his comments in the TIP thread
>> and to ask if he would be interested in a patch adding this
>> functionality, and I have included his response below.  I would like
>> to hear people's comments/suggestions/ideas before I start working on
>> said patch.
>> Thanks,
>> -Mark
>> Michael Foord's Email:
>> =======================================
>> I would certainly be interested in adding this to unittest.
>> It needs a discussion of the API and the semantics:
>> * What should the methods be called? setup_class and teardown_class or
>> setupClass and teardownClass? For consistency with existing methods
>> the camelCase should probably be used.
>> * If the setupClass fails how should the error be reported? The
>> *easiest* way is for the failure to be reported as part of the first
>> test
>> * Ditto for teardownClass - again the easiest way is for it to be
>> reported as a failure in the last test
>> * If setupClass fails then should all the tests in that class be
>> skipped? I think yes.
>> Also details like ensuring that even if just a single test method from
>> a class is run the setupClass and teardownClass are still run. It
>> probably needs to go to python-dev or python-ideas for discussion.
>> All the best,
>> Michael
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas

More information about the Python-ideas mailing list