[Python-Dev] setUpClass and setUpModule in unittest

[Holger Krekel]

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?

> 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.

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