[TIP] Reusable test suites in nose

[Andres Riancho]

Michael,

    Both achieve the same, mine seems "simpler" since the code in the
different implementations is minimalism and doesn't even care about
the hackish decorator

Regards,

On Mon, Jan 7, 2013 at 5:35 PM, Michael Williamson <mike at zwobble.org> wrote:
> 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
>>
>>
>>



-- 
Andrés Riancho
Project Leader at w3af - http://w3af.org/
Web Application Attack and Audit Framework
Twitter: @w3af
GPG: 0x93C344F3