Debugging Python

Frithiof Andreas Jensen frithiof.jensen at removethis.ted.ericsson.dk
Tue Jan 13 10:48:13 CET 2004


"Peter Hansen" <peter at engcorp.com> wrote in message
news:4002AE9B.C51448FB at engcorp.com...

> ...., as it takes me only about twenty seconds to start a
> new test file and that's *without* using a template.

....in twenty seconds you can just about write "import unittest" ;-)

I find that a simple module will need about three to five tests for each
method in each class and probably some test data as well often yielding in
total *more* lines of test code than the module I want to test.

It is simple, stupid & boring code but still lines that have to be typed and
debugged.

*That* is tedious work. Always will be.

The benefit comes later - when improving and extending the module one can
immediately see if it breaks and also I find that if one cannot think of an
obvious way of testing some class/method/unit it is usually because the
interface is stupid and needs a redesign.

The real fun with unittest starts when using "other peoples code": I wrote
an accounts database module based on pySqlite for a horse racing program I
am (still!) writing for fun. That was not at all easy to get to run in such
a way as one could test the database functions properly with unittest. There
is a lot of massaging of data to test that the queries work as intended and
manual work to design SQL data that will yield simple tests.

OTOH I am pretty confident the implementation actually works and I even
think I understand the kinks in pySqlite's implementation of the python
database API too ;-).





More information about the Python-list mailing list