[TIP] Using one unit test with different input parameters

[Jonathan Lange]

On Sun, Jul 13, 2008 at 12:14 AM, Ben Finney
<bignose+hates-spam at benfinney.id.au> wrote:
> Robert Collins <robertc at robertcollins.net> writes:
>
>> You might like to look at bzrlib.tests.TestScenarioApplier.
> […]
>
> I've now migrated to this approach in a pilot project; it's working
> well, and I'll likely use it elsewhere. Thank you.
>
> It helps a lot that Bazaar is licensed under GPL :-)
>
>> When run, you'll have test ids like:
>> test_foo.TestSite.test_a(wessex)
>> test_foo.TestSite.test_a(example.com)
>> test_foo.TestSite.test_a(example.org)
>> test_foo.TestSite.test_b(wessex)
>> test_foo.TestSite.test_b(example.com)
>> test_foo.TestSite.test_b(example.org)
>>
>> Which is much nicer for debugging [than] a for loop within a single test.
>
> Those id values certainly would make it simpler to identify test
> cases. I don't know how to get them via the standard unittest
> infrastructure, though.
>
> I see that 'TestCase.id' is a method provided already by
> 'unittest.TestCase', and you're overriding it in the generated test
> case instances.
>
> What I don't see is anything that actually *uses* this method. I can
> find nothing in the standard library 'unittest' module that actually
> uses it.
>
> How are you getting these values at run time? A custom TestRunner
> class?

I'll answer for Rob: Yes.

Answering for myself, unittest uses TestCase,shortDescription in its
runner, and shortDescription is next to useless. It will return the
docstring of a test if it has one. Seeing the docstring in a test run
might *sound* like a good idea, but in the heat of debugging it's just
frustrating.

Bazaar's test runner has a lot of very nice features that I've wanted
to steal for Twisted for some time. Have a play with it.

jml