On Thu, Feb 11, 2010 at 11:18 AM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Olemis Lang wrote:
On Tue, Feb 9, 2010 at 8:10 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
Michael Foord <fuzzyman@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)
Just as a point of reference: zope.testing[1] has a "layer" feature which is used to support this usecase: a layer is a class namedd as an attribute of a testcase, e.g.:
class FunctionalLayer: @classmethod def setUp(klass): """ Do some expesnive shared setup. """ @classmethod def tearDown(klass): """ Undo the expensive setup. """
class MyTest(unittest.TestCase): layer = FunctionalLayer
The zope.testing testrunner groups testcase classes together by layer: each layer's setUp is called, then the testcases for that layer are run, then the layer's tearDown is called.
Other features:
- - Layer classes can define per-testcase-method 'testSetUp' and 'testTearDown' methods.
- - Layers can be composed via inheritance, and don't need to call base layers' methods directly: the testrunner does that for them.
These features has been in heavy use for about 3 1/2 years with a lot of success.
I really like the style and the possibility to control the scope of ( setUp | tearDown ) . That's something I'd really consider to be included in the API ... and if it was accompanied or integrated to something like the @Rule in the backend to make it look like an extension and thus provide «standar mechanism(s)» to get other similar features done outside stdlib too, well, much better ;o) I have to start using Zope ! Damn, I'm wasting my few most happy years ! PS: I confess that I didn't follow the thread @ Py-Ideas. I associated Nick comment to the @Rule because, in JUnit, this is implemented using something similar to Aspect Oriented Programming (something like before and after hooks ;o), and in that case the Pythonic (and IMHO more «explicit») translation could be context managers . Perhaps I misunderstood something in previous messages . -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: PEP 391 - Please Vote! - http://feedproxy.google.com/~r/TracGViz-full/~3/hY2h6ZSAFRE/110617