[Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 2:04 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> On 09/02/2010 19:00, Olemis Lang wrote:
>>
>> Sorry. I had not finished the previous message
>>
>> On Tue, Feb 9, 2010 at 1:55 PM, Olemis Lang<olemis at gmail.com>  wrote:
>>> On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang<olemis at gmail.com>  wrote:
>>>> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
>>>> <fuzzyman at voidspace.org.uk>  wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> Several
>>>>> authors of other Python testing frameworks spoke up *against* them, but
>>>>> several *users* of test frameworks spoke up in favour of them. ;-)
>>>>>
>>>>
>>>> +1 for having something like that included in unittest
>>>>
>>>>> I'm pretty sure I can introduce setUpClass and setUpModule without
>>>>> breaking
>>>>> compatibility with existing unittest extensions or backwards
>>>>> compatibility
>>>>> issues
>>>>
>>>> Is it possible to use the names `BeforeClass` and `AfterClass` (just
>>>> to be make it look similar to JUnit naming conventions ;o) ?
>>>
>>> Another Q:
>>>
>>>  - class setup method will be a `classmethod` isn't it ? It should not be
>>>     a regular instance method because IMO it is not bound to a particular
>>>     `TestCase` instance.
>>
>>   - Is it possible to rely on the fact that all class-level tear down
>>     methods will be guaranteed to run even if class-level setup
>>     method throws an exception ?
>
> Yes it will be a classmethod rather than an instance method.

+1

> I would expect
> that in common with instance setUp the tearDown would *not* be run if setUp
> fails. What would be nice would be an extension of addCleanUp so that it can
> be used by class and module level setUp. Clean-ups largely obsolete the need
> for tearDown anyway.
>

I really disagree. IMO I am -1 for having `addCleanUp` and so on added
to the core API (i.e. `TestCase` class). The same goes for test
resources (especially if that means to merge it with the API rather
than including it as a separate independent module). The use cases for
that feature are not, in general, basic use cases ('cause if they were
*simple*, setUp/tearDown would be a *simple* alternative to do the
same thing ;o).

I repeat that my opinion is that I am -1 for including each and every
feature needed for testing purposes jus because it's very (super)
useful to solve even many use cases (e.g. context managers, by
themselves, are an empty and abstract construct that solve a set of
problems *once they are implemented*, but the top-level abstractions
are not directly useful by themselves). It's an API. In JUnit there
are a lot of useful extensions implemented in `junit-ext` package &
Co. (and AFAICR that also includes integration testing & test
resources) and besides there are some other important features in
JUnit>=4.7 itself, *but not hard coded in TestCase* (e.g.
`org.junit.rules.ExternalResource`, ...) and also allowing extensions
(e.g. `org.junit.rules.TemporaryFolder`) using well established
mechanisms (e.g. inheritance) . This also has the benefit that the
responsibilities are distributed to a set of relevant objects
following well-known interaction patterns, rather than cluttering a
class with all sort of functionalities .

PS: I say this and I know that it's quite unlikely that you will
reconsider it in order to revert what's being done there . But, if we
take a look to JUnit>=4.7, just notice that resource management is not
an integral part of `TestCase` at all, and is performed in a more
structured way, consistent with the «standard» or officially supported
mechanism used to add any other extension to JUnit . Honestly I can
obviously see the differences with respect to `addCleanUp`
implementation as we know it today.

-- 
Regards,

Olemis.

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

Featured article:
TracGViz plugin downloaded more than 1000 times (> 300 from PyPI) -
http://feedproxy.google.com/~r/simelo-en/~3/06Exn-JPLIA/tracgviz-plugin-downloaded-more-than.html