On Thu, Feb 11, 2010 at 11:18 AM, Tres Seaver <tsea...@palladion.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Olemis Lang wrote: >> 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) > > 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 _______________________________________________ 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
