Unittest - How do I code lots of simple tests

[Peter Hansen]

Paul Moore wrote:
> 
> Peter Hansen <peter at engcorp.com> wrote in message news:<3F95A5DC.51828269 at engcorp.com>...
> > Paul Moore wrote:
> > >
> > > Can anyone suggest a more reasonable way of running this sort of
> > > table-driven test via unittest?
[snip]
> > No, you don't get the psychologically affirming "52 tests passed!"
> > without changes to the TestRunner, but I assume the non-cosmetic part
> > of this is more your concern right now...
> 
> I don't see the remainder of the problem as "non-cosmetic". The error
> report I get (or rather the information it offers) is
> 
>     1 test failed - pass count is 25 instead of 52.
> 
> But that doesn't tell me *which* tests failed.
> 
> The key point here is that I'm NOT running one test - I really am
> running 52 distinct tests. OK, they are all very similar, differing
> only in the data - but for pity's sake, isn't that what an object
> oriented structure is supposed to make easy???

Well, look at it this way.  Using the built-in assertEquals() and
similar functions is a way of explicitly asking for a test method to 
abort, and for the framework to continue on with the next test
method.  If you don't want that behaviour, nothing's forcing you
to use assertEqual().

Instead, just write up your own comparison routine, which doesn't
abort, and have verbose output for each failure.  Something I've
done repeatedly in the past is to have a routine which says simply
(upon failure) "case %s: expected %s, result %s" and then substitute 
in the test case input, the expected value, and the actual result.

The part that is "cosmetic" is insisting that this has to result
in the framework reporting the as individual "test" failures.  To
do that, you need more extensive modifications, because unittest
has a clear, simple definition of what constitutes a test, and 
individual comparisons inside a testMethod() are not it... it's the
whole test method that is a test.

After all, just because a test has two self.assertEquals() and a single
self.assert_() doesn't necessarily mean it's *three* tests.

As Anthony B. wrote, you're testing one "aspect" or something... don't
think of tests as calls to assertXxxx() methods, think of them as 
collections of such calls.

-Peter