On 09/02/2010 21:57, Ben Finney 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.
I've used unittest for long running functional and integration tests (in
both desktop and web applications). The infrastructure it provides is
great for this. Don't get hung up on the fact that it is called
unittest. In fact for many users the biggest reason it isn't suitable
for tests like these is the lack of shared fixture support - which is
why the other Python test frameworks provide them and we are going to
bring it into unittest.
Michael
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).
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in perpetuity, without
prejudice to my ongoing rights and privileges. You further represent that you
have the authority to release me from any BOGUS AGREEMENTS on behalf of your
employer.
_______________________________________________
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
