Ian Bicking: the old part of his blog

Comment

Itamar: I know you can loop over the input, use setUp and tearDown, etc. But it's not very convenient. Take the example from Dive Into Python -- it tests a bunch of known integer to roman numeral conversions. The unit test isn't much of a unit, because the first conversion that fails causes the entire conversion test to fail. So you don't see that ten of the conversions worked, but five didn't. If one fails, you don't get to see if any of the later ones failed. Not a big deal in roman numerals, but that's a trivial example. When you are working through corner cases one by one, it's nice to be able to see and rerun each failure individually, and unittest doesn't give that sort of granularity. (I don't want to define 100 methods to test 100 possible input/output combinations either)

Chris: yes, I end up adding this functionality in subclasses. Unfortunately it doesn't work well with unittest.main. As Jeremy notes (and I tried to imply) unittests that take arguments to their __init__ don't have proper names (even arbitrary names), and collecting them for main() is unintuitive. They work, and maybe that means that unittest.TestCase is a fine class (if not perfect), but these instances don't fit into the system well.

Anyway, thanks all for the suggestions. I'm downloading them and it looks like there's some good stuff in these.
Comment on Unittest Rant
by Ian Bicking