[TIP] Supporting multiple fixtures for a test suite

Gary Bernhardt gary.bernhardt at gmail.com
Thu Jan 3 18:57:38 PST 2008


On Jan 3, 2008 8:09 PM, Titus Brown <titus at caltech.edu> wrote:
>
> Not that I know of, although my guess is that the Zope folk have some
> fantastic, but unproselytized, testing tools that probably do this
> automatically by actually reading the mind of the original test coder
> and doing what the person *actually* wanted to do.  But I digress...
>
> Have you thought about importing the actual test code from a common
> module, and providing different fixtures?  While I don't know that this
> code actually works, it *should* work in nose ;)

I think I'll go with this approach.  For some reason, I hadn't thought
of putting the setup/teardown at the package level, rather than the
module level (thanks Kumar).  That will solve most of my duplication
fears, although I will still need to manually duplicate every test
module in the child packages.  I imagine there's probably some way to
inspect the parent package at import time and dynamically duplicate
its module structure, but... no. :)

And I'll definitely switch to wsgi_intercept.  I can't believe I
forgot about it!  I spent about an hour of my life basically
reimplementing it... poorly.

Thanks for your help guys.

> ---
> # test-WSGI-only.py
>
> from common_tests import test*
>
> def setup():
>   # start up paste.fixture
>
> def teardown():
>   # teardown paste.fixture
>
> ---
> # test-live-site.py
>
> from common_tests import test*
>
> def setup():
>    # start up live site
>
> def teardown():
>    # tear down live site
> ---
>
> Once you have the tests installed with the different enclosing module
> names, then it's simply a matter of choosing whether or not to run them.
> How to do this depends on your testing framework, though.
>
> I completely agree that NOT doing this sort of thing explicitly will
> lead to you shooting yourself in your foot down the road...
>
> cheers,
> --titus
>

-- 
Gary
http://blog.extracheese.org



More information about the testing-in-python mailing list