Home Original page

How do I code lots of simple tests

Paul Moore pf_moore at yahoo.co.uk
Tue Oct 21 16:16:06 EDT 2003 
One of the things I really dislike about Unittest (compared, say, to a
number of adhoc testing tricks I've used in the past, and to Perl's
"standard" testing framework) is that the testcase-as-a-class model
tends to imply a relatively high granularity in testing.

A good example of this comes from "Dive Into Python"
(http://diveintopython.org) section 7.3. Here, the author has written
a module which converts numbers to Roman numerals. The test case is
then

class KnownValues(unittest.TestCase):
    knownValues = ( (1, 'I'), ... # 50-plus specific cases

    def testToRomanKnownValues(self):
        """toRoman should give known result with known input"""
        for integer, numeral in self.knownValues:
            result = roman.toRoman(integer)
            self.assertEqual(numeral, result)

Now, to my mind, the big problem here is that this *isn't* one test,
but rather 50 (or more). OK, the same checks are done if everything
succeeds, but

1. If a test fails, the rest are skipped! If there's a pattern to the
   failures (the code handles numbers ending in 4 and 9 wrongly, for
   example) it's much easier to find if all of the checks are
   reported.
2. Psychologically, "52 tests succeeded" is a much bigger boost than
   "1 test succeeded" (albeit this test covered 52 cases). And it's
   not just psychology - we really *did* test 52 distinct conditions.

The only way I can see of producing the "true" number of tests is via
some form of ugly hack like

test_values = ((1, 'I'), ...)

class KnownValues(unittest.TestCase):
    pass

for arabic, roman in test_values:
    def test(self):
        result = roman.toRoman(arabic)
        self.assertEqual(roman, result)
    setattr(KnownValues, 'test_%s_%s' % (arabic, roman), test)

But I can't really see that as the "right approach".

Can anyone suggest a more reasonable way of running this sort of
table-driven test via unittest?

Maybe I should use doctest instead, but to be honest, I prefer the
overall infrastructure of unittest (for real tests). It's just this
particular issue that really bugs me...

Paul.
-- 
This signature intentionally left blank
More information about the Python-list mailing list