Let's unit-test like it's 1999.

by Charles Miller on June 23, 2003

Mark Pilgrim links to a python-list post; Python Considered Harmful.

Debugging is a mess. The problem is that I tend to "stub" things a lot, or reference functions that have not yet been written (they're in the design doc, okay, so I know what their interfaces will be, I just haven't written them yet!). With a compiled language I run the compiler and linker and it tells me "hey stupid, you're missing something". With Python, I run it, and it tells me "doh, you forgot to create a method for 'checksum_packet'. I run it again, it tells me 'doh, you forgot to create a method for 'register_connection'. I run it again.... ad nauseum.

Reading through the replies, it astonished me that nobody in the supposedly enlightened Python community was suggesting pervasive unit testing as a substitute for compile-time type checking, as Bruce Eckel did so eloquently not long ago. (Mark also linked to the Eckel article directly below the link to the post).

After reading the whole thread, I finally looked up at the date at the top: the post was made in 1999. Ah, of course. Back in 1999, the sort of pervasive unit testing required to properly substitute for strong typing was still one of those arcane secrets slowly leaking out of that strange Smalltalk community. Nowadays, xUnit has been ported to every language under the sun (and even several that don't see the light of day), and most conscientious coders feel guilty if they write anything that doesn't have a good suite of tests. Certainly you wouldn't get away with a mailing-list post like that without ten people quoting Kent Beck at you.

Then, of course, I realised just how recent 1999 was. I started thinking “Do things change that fast?” Then I realised, no they don't. Things still changed slowly, but if you only see the back end of the exponential adoption curve, it looks a lot faster.

Previously: Google's Broken Weblog Backlash

Next: Going home...