Michael Foord <fuzzy...@voidspace.org.uk> writes: > 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. ;-)
I think the perceived need for these is from people trying to use the ‘unittest’ API for test that are *not* unit tests. That is, people have a need for integration tests (test this module's interaction with some other module) or system tests (test the behaviour of the whole running system). They then try to crowbar those tests into ‘unittest’ and finding it lacking, since ‘unittest’ is designed for tests of function-level units, without persistent state between those test cases. Is there a better third-party framework for use in these cases? As Olemis points out later in this thread, I don't think it's good for the ‘unittest’ module to keep growing for uses that aren't focussed on unit tests (as contrasted with other kinds of tests). -- \ “The industrial system is profoundly dependent on commercial | `\ television and could not exist in its present form without it.” | _o__) —John Kenneth Galbraith, _The New Industrial State_, 1967 | Ben Finney _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
