On Tue, Feb 9, 2010 at 8:10 PM, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > Michael Foord <fuzzy...@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/ _______________________________________________ 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
