On Tue, Feb 9, 2010 at 8:10 PM, Ben Finney <ben+python at benfinney.id.au> wrote: > Michael Foord <fuzzyman at voidspace.org.uk> writes: > >> 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. > > I would argue that one of the things that makes ‘unittest’ good is that > it makes it difficult to do the wrong thing — or at least *this* wrong > thing. Fixtures persist for the lifetime of a single test case, and no > more; that's the way unit tests should work. > > Making the distinction clearer by using a different API (and *not* > extending the ‘unittest’ API) seems to be the right way to go. > If that means that development should be focused on including mechanisms to make unittest more extensible instead of complicating the current «relatively simple» API , then I agree . I think about unittest as a framework for writing test cases; but OTOH as a meta-framework to be used as the basic building blocks to build or integrate third-party testing infrastructures (and that includes third-party packages ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Free milestone ranch Download - mac software - http://feedproxy.google.com/~r/TracGViz-full/~3/rX6_RmRWThE/
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