Here's the syntax and functionality I prefer:<br><br> @permute( x=[1, 2], y=[0, 1, 3] )<br> def test_addition(self, x, y):<div> self.assertEqual( x + y, 2 )<br></div><br>... resulting in *six* tests (one for each permuted combination) and of these two passes and four fails. In my test tool, each of the six tests are tagged with each param and value so nose's attrib plugin can select them:<br>
<br> test_addition.x=1<br>
test_addition.y=0<br>
<br>
test_addition_2.x=1<br>
test_addition_2.y=1<br>
<br>
test_addition_3.x=1<br>
test_addition_3.y=3<br>
<br>
...<br>
<br>This permuting helps us write a single test for an API method, for example, that spans multiple versions and environments (plus other params). The current way that the tool works, the new tests are created and added to the test class on module import - so from unittest's perspective they look like normal test methods. In other words, nose doesn't need to do anything special to deal with them and I suspect unittest2 won't either. That said, I would prefer not to do the heavy work of permuting tests on module import, so if there's a better way to do this, I would be interested in hearing about it.<br>
<br>Thanks.<br>- Rob<br><br><br><div class="gmail_quote">On Thu, Aug 5, 2010 at 10:20 PM, Brian Curtin <span dir="ltr"><<a href="mailto:brian.curtin@gmail.com">brian.curtin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im">On Thu, Aug 5, 2010 at 20:56, Michael Foord <span dir="ltr"><<a href="mailto:fuzzyman@voidspace.org.uk" target="_blank">fuzzyman@voidspace.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On 06/08/2010 02:49, Jesse Noller wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Thu, Aug 5, 2010 at 9:31 PM, Michael Foord<<a href="mailto:fuzzyman@voidspace.org.uk" target="_blank">fuzzyman@voidspace.org.uk</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On 06/08/2010 02:23, Jesse Noller wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
[snip...]<br>
ps: If nose2/unittest2 could find it in it's shiny new innocent heart<br>
to say, have support for test generators; I'd die happy.<br>
<br>
<br>
</blockquote>
Well there's another discussion :-)<br>
<br>
It would be very simple to support parameterized tests (of some form), where<br>
the number of tests can be known at test load time. Supporting generative<br>
tests - where the tests are generated at *test run time* is uglier.<br>
<br>
Would parameterized tests, where the tests are all generated at test load<br>
time, suffice or do you have a use case for generative tests where the tests<br>
have to be generated whilst the tests are running and not when the tests are<br>
loaded?<br>
<br>
Michael<br>
<br>
</blockquote>
For me? To be honest, 98% of my (and the people around me) use cases<br>
are the parameterized case - the test generator syntax is just pure<br>
awesome (Ok, so I really like it) tests generated at run time tends to<br>
rub most people wrong :)<br>
<br>
</blockquote>
<br></div>
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.<br>
<br>
Could you give me an example usage please, so I can think about how to support it (probably initially as a plugin).<br>
<br>
All the best,<br>
<br>
Michael</blockquote><div><br></div></div><div>I've wanted to do something like this in the past...</div><div><br></div><div>@unittest.params((1, 1), (2, 0), (1, 2))</div><div>def test_addition(self, x, y):</div><div>
self.assertEqual(x + y, 2)</div>
<div><br></div><div>...resulting in two passes, one fail.</div><div><br></div><div>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.</div>
</div>
<br>_______________________________________________<br>
testing-in-python mailing list<br>
<a href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a><br>
<a href="http://lists.idyll.org/listinfo/testing-in-python" target="_blank">http://lists.idyll.org/listinfo/testing-in-python</a><br>
<br></blockquote></div><br>