Hello all,
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'm pretty sure I can introduce setUpClass and setUpModule without
breaking compatibility with existing unittest extensions or backwards
compatibility issues - with the possible exception of test sorting.
Where you have a class level setUp (for example creating a database
connection) you don't want the tearDown executed a *long* time after the
setUp. In the presence of class or module level setUp /tearDown (but
only if they are used) I would expect test sorting to only sort within
the class or module [1]. I will introduce the setUp and tearDown as new
'tests' - so failures are reported separately, and all tests in the
class / module will have an explicit skip in the event of a setUp failure.
A *better* (more general) solution for sharing and managing resources
between tests is to use something like TestResources by Robert Collins.
http://pypi.python.org/pypi/testresources/
A minimal example of using test resources shows very little boilerplate
overhead from what setUpClass (etc) would need, and with the addition of
some helper functions could be almost no overhead. I've challenged
Robert that if he can provide examples of using Test Resources to meet
the class and module level use-cases then I would support bringing Test
Resources into the standard library as part of unittest (modulo
licensing issues which he is happy to work on).
I'm not sure what response I expect from this email, and neither option
will be implemented without further discussion - possibly at the PyCon
sprints - but I thought I would make it clear what the possible
directions are.
All the best,
Michael Foord
[1] I *could* allow sorting of all tests within a module, inserting the
setUpClass / tearDownClass in the right place after the sort. It would
probably be better to group tests per class anyway and in fact the
existing suite sorting support may do this already (in which case it
isn't an issue) - I haven't looked into the implementation.
--
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.
--
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
