[Python-Dev] setUpClass and setUpModule in unittest

Olemis Lang olemis at gmail.com
Thu Feb 11 16:11:12 CET 2010

On Thu, Feb 11, 2010 at 9:41 AM, Olemis Lang <olemis at gmail.com> wrote:
> On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>> On 11/02/2010 12:30, Nick Coghlan wrote:
>>> Michael Foord wrote:
>>>> I'm not sure what response I expect from this email, and neither option
>>>> will be implemented without further discussion - possibly at the PyCon
>>>> sprints - but I thought I would make it clear what the possible
>>>> directions are.
>>> I'll repeat what I said in the python-ideas thread [1]: with the advent
>>> of PEP 343 and context managers, I see any further extension of the
>>> JUnit inspired setUp/tearDown nomenclature as an undesirable direction
>>> for Python to take.
>>> Instead, I believe unittest should be adjusted to allow appropriate
>>> definition of context managers that take effect at the level of the test
>>> module, test class and each individual test.
>>> For example, given the following method definitions in unittest.TestCase
>>> for backwards compatibility:
>>>   def __enter__(self):
>>>     self.setUp()
>>>   def __exit__(self, *args):
>>>     self.tearDown()
>>> The test framework might promise to do the following for each test:
>>>   with get_module_cm(test_instance): # However identified
>>>     with get_class_cm(test_instance): # However identified
>>>       with test_instance: # **
>>>         test_instance.test_method()
> What Nick pointed out is the right direction (IMHO), and the one I had
> in mind since I realized that unittest extensibility is the key
> feature that needs to be implemented . I even wanted to start a
> project using this particular architecture to make PyUnit extensible.
> It's too bad (for me) that I don't have time at all, to move forward
> an just do it .
> :(
> I need days with 38 hrs !!! (at least)
> :$
>> Well that is *effectively* how they would work (the semantics) but I don't
>> see how that would fit with the design of unittest to make them work
>> *specifically* like that - especially not if we are to remain compatible
>> with existing unittest extensions.
> AFAICS (so not sure especially since there's nothing done to criticize
> ;o) is that backwards compatibility  is not the main stopper ...
>> If you can come up with a concrete proposal of how to do this then I'm happy
>> to listen. I'm not saying it is impossible, but it isn't immediately
>> obvious. I don't see any advantage of just using context managers for the
>> sake of it and definitely not at the cost of backwards incompatibility.
> ... but since I have nothing I can show you , everything is still in my mind ...

The idea (at least the one in my head ;o) is based on the features
recently introduced in JUnit 4.7, especially the @Rule




Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Free milestone ranch Download - mac software  -

More information about the Python-Dev mailing list