[Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Thu, Feb 11, 2010 at 11:18 AM, Tres Seaver <tseaver at 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 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)
>
> 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