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. -- \ “I object to doing things that computers can do.” —Olin Shivers | `\ | _o__) | Ben Finney _______________________________________________ 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
