On 10:42 pm, fuzzyman at voidspace.org.uk wrote: >On 09/02/2010 21:57, Ben Finney wrote: >>Michael Foord<fuzzyman at 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 >> 18unittest 19 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 >> 18unittest 19 and finding it lacking, since 18unittest 19 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. For what it's worth, we just finished *removing* support for setUpClass and tearDownClass from Trial. Jean-Paul
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