[Python-ideas] Test Class setup and teardown in unittest
brett at python.org
Thu Jan 21 20:12:07 CET 2010
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 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
> class MyTest(TestCase):
> def setUp(self):
> if not self.ClassIsSetup:
> 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.
> 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
> * 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,
> Python-ideas mailing list
> Python-ideas at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas