Testing dynamic languages

grkuntzmd at gmail.com grkuntzmd at gmail.com
Sat Apr 4 19:30:27 CEST 2009


This may be obvious but, clearly there are (at least) two general
types of errors: those caused by data external to the program and
those caused by bugs in the program. For all inputs coming into the
program from outside, such as user inputs and data coming over a
network, the inputs must be completely checked -- always assume that
they will be incorrect and are intended to crash your code -- be
pleasantly surprised when they are not :-). Check for all bad inputs.

If the data are from inside the program, the assumption may be that
they are good and if not, it was a bug. I suppose you can write unit
tests on each routine to see that the methods that routine calls are
with valid arguments (using mocks). I actually tried this in a Java
program using JMockit; it was tedious, but it did catch a few
"potential" bugs. I would love to say that I ALWAYS remember the input
and output condition of every subroutine I write, but I just finished
a new feature for a company project that involved 100+ routines and
classes and I admit that I don't always remember which ones can return
null and which always return empty arrays, for example, even though I
try to write JavaDocs at the top of each routine. By mocking these
routines, I can check that the caller always handles each case
gracefully.



More information about the Python-list mailing list