On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > 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).
My general view these days is that for unit tests there is practically not much of a a difference in using unittest, nose or py.test (give or take reporting niceness and flexibility). However, Functional and integration tests involve more complex fixture management and i came to find the setup/teardown on classes and modules lacking. Which is why there is testresources from Rob and funcargs in py.test. The latter allow to setup and teardown resources from a fixture factory which can determine the setup/teardown scope and perform whole-session caching without changing test code. In my Pycon testing tutorial (http://tinyurl.com/ya6b3vr ) i am going to exercise it in depth with beginners and here are docs: http://pytest.org/funcargs.html One nice bit is that you can for a given test module issue "py.test --funcargs" and get a list of resources you can use in your test function - by simply specifying them in the test function. In principle it's possible to port this approach to the stdlib - actually i consider to do it for the std-unittest- running part of py.test because people asked for it - if that proves useful i can imagine to refine it and offer it for inclusion. cheers, holger _______________________________________________ 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
