This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Yaroslav.Halchenko, abingham, brian.curtin, diekhans, eric.araujo, eric.snow, exarkun, ezio.melotti, fperez, michael.foord, nchauvat, ncoghlan, pere.martir, pitrou, r.david.murray, terry.reedy
Date 2012-01-17.11:33:15
SpamBayes Score 1.1889895e-07
Marked as misclassified No
Message-id <1326799996.01.0.606666939523.issue12600@psf.upfronthosting.co.za>
In-reply-to
Content
Back on topic...

While I can see the advantage of parameterisation at the level of individual tests, I'm not at all clear on the benefits at the TestCase level.

For CPython's own test suite, if we want to share tests amongst multiple test cases, we just use ordinary inheritance. You get parameterisation pretty much for free with that approach:

class _BaseTest(object):
    # Tests go here
    # setUp and tearDown often go here, too

class FooTestCase(_BaseTest, TestCase):
    # Parameter settings go here

class BarTestCase(_BaseTest, TestCase):
    # Parameter settings go here

If you want to get data-driven about it, you can also do dynamic TestCase creation based on a sequence of parameter sets.

So, absent a compelling explanation for why the ordinary inheritance mechanisms aren't adequate, I'd be in favour of closing this one.
History
Date User Action Args
2012-01-17 11:33:16ncoghlansetrecipients: + ncoghlan, terry.reedy, exarkun, pitrou, diekhans, ezio.melotti, eric.araujo, r.david.murray, michael.foord, brian.curtin, fperez, Yaroslav.Halchenko, nchauvat, abingham, eric.snow, pere.martir
2012-01-17 11:33:16ncoghlansetmessageid: <1326799996.01.0.606666939523.issue12600@psf.upfronthosting.co.za>
2012-01-17 11:33:15ncoghlanlinkissue12600 messages
2012-01-17 11:33:15ncoghlancreate