[Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Thu, Feb 11, 2010 at 10:11 AM, Olemis Lang <olemis at gmail.com> wrote:
> 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
>
> ;o)
>

.. [1] Writing your own JUnit extensions using @Rule | JUnit.org
         (http://www.junit.org/node/580)

-- 
Regards,

Olemis.

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

Featured article:
setUpClass and setUpModule in unittest | Python | Dev  -
http://feedproxy.google.com/~r/TracGViz-full/~3/x18-60vceqg/806136