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

[Michael Foord]

On 21/01/2010 19:12, Brett Cannon wrote:
>
>
> On Wed, Jan 20, 2010 at 16:38, Mark Roddy <markroddy at gmail.com 
> <mailto: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 <mailto: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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100121/2b460b25/attachment.html>