Austin Bingham <austin.bing...@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 <rep...@bugs.python.org> wrote: > > Terry J. Reedy <tjre...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue12600> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12600> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com