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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4