Unittest - How do I code lots of simple tests

[Ian Bicking]

On Wednesday, October 22, 2003, at 08:18 AM, Peter Hansen wrote:
> 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.

What we really want isn't granularity inside a testMethod().  A 
TestCase can currently have more than one test already (different test* 
methods) -- what we want is to generalize that.  Instead of just def 
testA(self), def testB(self), etc., we want a testCompare(self, input, 
output), where the input and output comes from some list of inputs and 
known outputs (bonus if that list also contains names so we can address 
particular tests).

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org