[TIP] paramterized or generative tests [was nose2: the nosening]

jason pellerin jpellerin at gmail.com
Fri Aug 6 08:36:30 PDT 2010

And in a strange coincidence, I've just updated nose2 with a
compatibility shim to make nose-style implicit generator tests work
(it just looks for generator functions and sets .testGenerator).


On Fri, Aug 6, 2010 at 11:17 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 06/08/2010 03:20, Brian Curtin wrote:
> On Thu, Aug 5, 2010 at 20:56, Michael Foord <fuzzyman at voidspace.org.uk>
> wrote:
>> On 06/08/2010 02:49, Jesse Noller wrote:
>>> On Thu, Aug 5, 2010 at 9:31 PM, Michael Foord<fuzzyman at voidspace.org.uk>
>>>  wrote:
>>>> On 06/08/2010 02:23, Jesse Noller wrote:
>>>>> [snip...]
>>>>> ps: If nose2/unittest2 could find it in it's shiny new innocent heart
>>>>> to say, have support for test generators; I'd die happy.
>>>> Well there's another discussion :-)
>>>> It would be very simple to support parameterized tests (of some form),
>>>> where
>>>> the number of tests can be known at test load time. Supporting
>>>> generative
>>>> tests - where the tests are generated at *test run time* is uglier.
>>>> Would parameterized tests, where the tests are all generated at test
>>>> load
>>>> time, suffice or do you have a use case for generative tests where the
>>>> tests
>>>> have to be generated whilst the tests are running and not when the tests
>>>> are
>>>> loaded?
>>>> Michael
>>> For me? To be honest, 98% of my (and the people around me) use cases
>>> are the parameterized case - the test generator syntax is just pure
>>> awesome (Ok, so I really like it) tests generated at run time tends to
>>> rub most people wrong :)
>> Ok. Good syntax is generally a good thing, and there is no reason why a
>> generator couldn't be called at test load time to generate the tests -
>> perhaps in conjunction with a decorator so we don't have to do horrible
>> introspection to determine if something is a test generator or not.
>> Could you give me an example usage please, so I can think about how to
>> support it (probably initially as a plugin).
>> All the best,
>> Michael
> I've wanted to do something like this in the past...
> @unittest.params((1, 1), (2, 0),  (1, 2))
> def test_addition(self, x, y):
>     self.assertEqual(x + y, 2)
> ...resulting in two passes, one fail.
> I think I already mentioned this or something like it on the Roundup issue
> for this topic. I have part of a patch around somewhere, but it's far from
> complete.
> Ok, I've just added this to the moduleloading plugin tool. Pulling it over
> into unittest itself would be trivially easy. Whether we should add
> parameterized or generated tests (or even both?) to core unittest - or maybe
> just pull in the moduleloading plugin when plugins are merged into unittest
> - is still an open question.
> Michael
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
> READ CAREFULLY. By accepting and reading this email you agree, on behalf of
> your employer, to release me from all obligations and waivers arising from
> any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
> shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
> non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have
> entered into with your employer, its partners, licensors, agents and
> assigns, in perpetuity, without prejudice to my ongoing rights and
> privileges. You further represent that you have the authority to release me
> from any BOGUS AGREEMENTS on behalf of your employer.
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python

More information about the testing-in-python mailing list