[Python-ideas] Test Class setup and teardown in unittest
markroddy at gmail.com
Thu Jan 21 20:44:54 CET 2010
On Thu, Jan 21, 2010 at 2:15 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 21/01/2010 19:12, Brett Cannon 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?
> unittest creates one instance *per test method*. That way tests are isolated
> from each other in separate instances. __init__ and __del__ are (or would
> be) run per test method.
>> 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
> READ CAREFULLY. By accepting and reading this email you agree, on behalf of
> your employer, to release me from all obligations and waivers arising from
> any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
> shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
> non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have
> entered into with your employer, its partners, licensors, agents and
> assigns, in perpetuity, without prejudice to my ongoing rights and
> privileges. You further represent that you have the authority to release me
> from any BOGUS AGREEMENTS on behalf of your employer.
Also, if you did a teardown (of any type/scope) in __del__ you
wouldn't be able report errors occurring in the method as __del__
isn't called until the object is no longer referenced (possibly not
occurring until the interpreter shuts down).
More information about the Python-ideas