[issue12600] Support parameterized TestCases in unittest

[Austin Bingham]

Austin Bingham <austin.bingham at gmail.com> added the comment:

Yes, in some sense that's what I'm thinking of. But one problem with
this straightforward approach is that it doesn't scale well. If I've
got many TestCases, each if which I want to parameterize, I have to
create subclasses for each parameterization. If I add a new
parameterization, of course I have to add new subclasses for each.
Even worse, if my parameterizations are dynamically generated (e.g. if
my parameterizations are based on installed plugins or something),
then this naive approach just breaks down.

There are, as has been mentioned, various ways to implement quite
sophisticated parameterized test cases purely by subclassing the
existing loaders, runner, and TestCase functionality. On the other
hand (and recognizing that I may well be missing something), it's not
particularly straightforward to do so, and it feels like a bit more of
a hack than I would like. There are a lot of moving parts in unittest,
and when I have to start fiddling with one to get special new behavior
I always worry that I might subtly break something else...but maybe
I'm just being neurotic ;)

So, I'll put forward two arguments for official support for
parameterized test cases. The first is what I mentioned above:
implementing it extrinsic to the existing system seems non-obvious and
complex, and thus error prone. Putting official support in unittest
would mean nobody else ever had to worry about it. On the other hand,
assuming that parameterized test cases can be fully and cleanly
implemented without touching unittest, this also argues that someone
should just create an external package to do so, and leave unittest
alone.

The second argument is symmetry. If you implement parameterization of
individual tests, it seems like the logic for justifying them really
could be generalized for collections of tests, both "cases" and
"suites". I admit that this is just a gut feeling, but there you go.

Ultimately, I'm less concerned that any changes are made to unittest
than I am that the issue is given due consideration. Heck, a proper
"fix" might be to just add a section to the docs describing how one
might implement parameterized testcases.

On Sat, Jul 23, 2011 at 12:04 AM, Terry J. Reedy <report at bugs.python.org> wrote:
>
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> David, is this the sort of thing you mean?
>
> @skip # so do not run without backend
> class AbstractDB2Testcase:
>  backend = None
>  <code>
>
> class PostgressDB2Testcase(AbstractDB2Testcase):
>  backend = postgress # well, enough info to fine it
>
> ...
>
> If so, I think we should close this.
>
> ----------
> nosy: +terry.reedy
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12600>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12600>
_______________________________________