[Python-Dev] setUpClass and setUpModule in unittest

[Guido van Rossum]

On Thu, Feb 11, 2010 at 11:26 AM, Holger Krekel <holger.krekel at gmail.com> wrote:
> Hi Guido,
>
> On Thu, Feb 11, 2010 at 7:11 PM, Guido van Rossum <guido at python.org> wrote:
>> On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>>> The next 'big' change to unittest will (may?) be the introduction of class
>>> and module level setUp and tearDown. This was discussed on Python-ideas and
>>> Guido supported them. They can be useful but are also very easy to abuse
>>> (too much shared state, monolithic test classes and modules). Several
>>> authors of other Python testing frameworks spoke up *against* them, but
>>> several *users* of test frameworks spoke up in favour of them. ;-)
>>
>> Hi Michael,
>>
>> I have skimmed this thread (hence this reply to the first rather than
>> the last message), but in general I am baffled by the hostility of
>> testing framework developers towards their users. The arguments
>> against class- and module-level seUp/tearDown functions seems to be
>> inspired by religion or ideology more than by the zen of Python. What
>> happened to Practicality Beats Purity?
>
> Hostility against users?  I have not heart that feedback from my users
> yet - or am i missing some meaning of your words?

Sorry for the sweeping generality. I was referring to one or more
posts (I don't recall by whom) arguing against including class/module
setup/teardown functionality based on it being against the notion of
unittesting or something like that. I'm sorry, but the thread is too
long for me to find the specific post. But I'm pretty sure I saw
something like that.

>> The potential for abuse in and of itself should not be an argument
>> against a feature; it must always be weighed against the advantages.
>
> sure.
>
>> The argument that a unittest framework shouldn't be "abused" for
>> regression tests (or integration tests, or whatever) is also bizarre
>> to my mind. Surely if a testing framework applies to multiple kinds of
>> testing that's a good thing, not something to be frowned upon?
>
> If an approach has known limitations it's also good to point them out.
> Also ok to disregard them and still consider something useful enough.
>
>> There are several alternative testing frameworks available outside the
>> standard library. The provide useful competition with the stlib's
>> unittest and doctest modules, and useful inspiration for potential new
>> features. They also, by and large, evolve much faster than a stdlib
>> module ever could, and including anyone of these in the stdlib might
>> well be the death of it (just as unittest has evolved much slower
>> since it was included).
>
> Fully agreed :)
>
>> But unittest *is* still evolving, and there is no reason not to keep
>> adding features along the lines of your module/class setUp/tearDown
>> proposal (or extra assertions like assertListEqual, which I am happy
>> to see has been added).
>
>>
>> On the other hand, I think we should be careful to extend unittest in
>> a consistent way. I shuddered at earlier proposals (on python-ideas)
>> to name the new functions (variations of) set_up and tear_down "to
>> conform with PEP 8" (this would actually have violated that PEP, which
>> explicitly prefers local consistency over global consistency).
>
> If that was me you refer to - i followed PEP8 5 years ago when
> introducing setup_class/module and i still stand by it, it was
> supposed to be a more pythonic alternative and i consider PEP8 as part
> of that.  But i agree - introducing it to std-unittest now makes not
> much sense due to local consistency reasons.

Ok let's drop it then.

> I appreciate Michael's effort to help advance testing - we have a good
> private discussion currently btw - and i am happy to collaborate with
> him on future issues, setupClass or not :)
>
> cheers,
> holger
>



-- 
--Guido van Rossum (python.org/~guido)