Hi Guido, On Thu, Feb 11, 2010 at 7:11 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord <fuzzyman@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