Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Python rocks for testing

I'm testing a custom XML-object mapping library. Writing test cases in Python is incredibly pleasant:

class BaseParseTest(comfychair.TestCase):
    def runtest(self):
        tt = pywbem.tupletree.xml_to_tupletree(self.input_xml)
        result = pywbem.tupleparse.parse_any(tt)
        self.assert_equal(result, self.expected_obj)

class KeyBinding_Numeric_Test(BaseParseTest):
    input_xml = """<KEYBINDING NAME="answer">
        <KEYVALUE VALUETYPE="numeric">42</KEYVALUE>
    </KEYBINDING>"""
    expected_obj = {"answer": 42}

and that's it! Rinse, repeat. Add more as problems are discovered.

I'm using my comfychair test library here, which is yet another rewrite of the JUnit idea, specialized for the kind of tests I often write.

In particular:

• It's easy to statically declare complex nested object structures. It would be in Perl or Ruby or Lisp too; it's hard in Java or C or C++. It's even hard to have an embedded multi-line XML document in those languages.
• It's easy to compare those nested objects.
• If something goes wrong, you're likely to get a nice traceback showing where things broke, and allowing use of the postmortem debugger.

It's only a matter of degree, but being 50% easier to create test cases has a compounding effect on the amount of test coverage.

Python has much weaker compile-time tests than say Java or C. The ease of writing tests tends to make up for this though, and to get you to a higher state than Java that merely compiles but is not yet tested.

posted Wed 6 Oct 2004 in /software/testing | link

Copyright (C) 1999-2007 Martin Pool.