[TIP] Reusable test suites in nose

[Michael Williamson]

Thanks Andres, that looks interesting -- assuming I've understood it
correctly, it seems pretty similar to what I had in style, although
less so in implementation.

Do you think there's any advantage in your approach over mine? In terms
of usage, it seems mainly to be a question of whether you prefer
inheritance or passing functions around.

On Mon, 7 Jan 2013 10:10:41 -0300
Andres Riancho <andres.riancho at gmail.com> wrote:

> Michael,
> 
>     I've found myself in your situation before and I've solved it by
> doing the following:
> 
> Define a Generic test class that holds all tests you want to run on
> all the different implementations, and decorate each test with
> @only_if_subclass:
>     http://sourceforge.net/apps/trac/w3af/browser/branches/threading2/core/data/bloomfilter/tests/generic_filter_test.py
> 
> Where @only_if_subclass is defined as:
>     http://sourceforge.net/apps/trac/w3af/browser/branches/threading2/core/controllers/tests/pylint_plugins/decorator.py
> 
> Then, simply create your specific tests that inherit from the generic
> test class:
>     http://sourceforge.net/apps/trac/w3af/browser/branches/threading2/core/data/bloomfilter/tests/test_cmmap_bloom.py
> 
>     only_if_subclass is where the (vodoo) magic lives, it makes sure
> the test is only run in the subclass (the ones defined in
> test_cmmap_bloom.py for example) and not in the generic test class.
> 
> Regards,
> 
> On Mon, Jan 7, 2013 at 8:58 AM, Michael Williamson <mike at zwobble.org>
> wrote:
> > Hello,
> >
> > When writing different implementations of the same interface, it's
> > useful to be able to run the same test suite against each different
> > implementation. I've quickly knocked up a bit of code to do just
> > that with nose -- is there something similar that already exists
> > elsewhere?
> >
> > The way it works is:
> >
> > There's a class called TestSuiteBuilder, which collects up all the
> > tests:
> >
> > https://github.com/mwilliamson/peachtree/blob/7724d6176cdc574208c771fec6d75ff736259d48/tests/suite_builder.py
> >
> > You then define your tests, which accept some number of arguments.
> > The idea is that the exact implementation of those arguments is
> > what will vary. In this case, I'm testing a general interface for a
> > virtual machine provider.
> >
> > https://github.com/mwilliamson/peachtree/blob/7724d6176cdc574208c771fec6d75ff736259d48/tests/provider_tests.py
> >
> > Then, you instantiate a test class with a specific implementation
> > using the "create" method:
> >
> > https://github.com/mwilliamson/peachtree/blob/7724d6176cdc574208c771fec6d75ff736259d48/tests/qemu_tests.py
> >
> > Michael
> >
> > _______________________________________________
> > testing-in-python mailing list
> > testing-in-python at lists.idyll.org
> > http://lists.idyll.org/listinfo/testing-in-python
> 
> 
>