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

[Mark Roddy]

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.
>
> Michael
>
>
>
> -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
>
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
> 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).

-Mark