[TIP] Supporting multiple fixtures for a test suite

[Ryan Freckleton]

If you have two test suites with the same tests, but different
fixtures, you could probably create a three-class hierarchy and have
the teardown/cleanup functions overloaded in the two child classes,
while the main body of functional tests defined in the parent class.

Hope this helps,

On Jan 3, 2008 1:26 PM, Gary Bernhardt <gary.bernhardt at gmail.com> wrote:
> I have a fairly complex client-server system with a suite of
> functional tests.  I want to be able to run the tests in two ways: by
> spawning the server and running normally; or with paste.fixture, which
> hooks the client directly to the WSGI app.  Supporting both test modes
> allows me to make a tradeoff whenever I run the tests: do I want them
> to be more complete (i.e., the full test mode with the server), or do
> I want them to be fast (i.e., with the short-circuited WSGI mode,
> which takes about half as long to run).  To put it simply, what I want
> is a single test suite that can choose between multiple fixtures.
>
> I've considered a couple solutions.  First, I could add a package that
> imports all of the functional tests, but adds its own setup and
> teardown methods.  I don't like this because the packages could
> accidentally go out of sync (i.e., I forget to mirror a module or a
> class from one to the other).  Second, I could add an environment
> variable that chooses between the fixtures.  I don't like this either
> because it's not obvious - you wouldn't know there are multiple
> fixtures unless you dug down into the fixtures themselves.
>
> So finally, the question I have is: how do you guys deal with
> overloaded tests like this?  Is there some standard way to do it that
> I've failed to google? :)
>
> --
> Gary
> http://blog.extracheese.org
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>



-- 
=====
--Ryan E. Freckleton