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

[Michael Foord]

On 06/08/2010 03:20, Brian Curtin wrote:
> On Thu, Aug 5, 2010 at 20:56, Michael Foord <fuzzyman at voidspace.org.uk 
> <mailto: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
>         <mailto: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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100806/9b2653ef/attachment.htm>