I’ve preached here before (more than once) about the virtues of Test-Driven Development (TDD), but never given it top billing, so here goes. Over the last twenty years I’ve seen the rise of Structured Programming and Object-Oriented Programming and Message Passing and the Relational Model and those are all good things, but TDD is the single biggest advance in my lifetime. It might (finally) turn software from an amateur’s kitchen to an engineering discipline. Herewith some more anecdotal evidence, and practical advice for Software Development managers. [Updated with pointers to PyUnit, NUnit and PHPUnit.]
Zeppelin Refactoring · I’m in the early stages of sketching in base infrastructure for Project Zeppelin which, if it works, you’ll be hearing a lot about here. Anyhow, for this one core module I sketched in a single class with the basic methods (all empty), then I wrote a test suite (using JUnit), a couple hundred lines of Java.
Then I sketched in all the code without worrying too much about getting the factoring right, just to make sure I understood the problem. There were bugs where I hadn’t, and I shook ’em out.
By the time I had, I realized that running it distributed across the network wouldn’t fly with everything in one class and without any fear, I ripped it all up and refactored it into three classes, which took a little less time than writing it initially. Once that was done, I realized that I’d got it wrong and that two of the classes were begging to be rolled back into one. This took a little less time than the first refactoring.
The key point is that ten years ago, I would have written the code, got it more or less working, and charged ahead with the rest of the system; when I later realized that the core module was factored poorly I would have been terrified of rebuilding it, and really would have pushed back on anyone who wanted to.
But with the tests there, and JUnit to run them all at a keystroke, the fear factor just evaporates. And furthermore, I wouldn’t be surprised if, when I get the rest of Zeppelin running, I’ll want to refactor the core module again; and so I will, and I won’t worry about it.
What’s happening is that I’m getting better software and (despite the fact that I’m investing time in building the test suite and more up-front refactoring), I’m convinced that I’m getting it quicker.
(For those of you who have already drunk the TDD kool-aid, I beg your indulgence for ranting away about what you already know. But based on what I see, a lot of people haven’t figured it out yet, and you’d be doing the world a favor if you did some ranting too.)
Practical Advice · If you’re a Java developer, go learn about JUnit and read some of the books and articles and just start using it. If you already know about JUnit and TDD and you’re not using it, you should be waking up in the night in a cold sweat, because you’re being less than professional.
If you’re working in some other language, go find out if that
language has a JUnit equivalent; I’ve heard tell of PyUnit
(dive in
here,
here, and
here)
and CUnit; for
.NET there’s
NUnit and (obvious when you think about
it, I guess)
PHPUnit.
Or, just roll your own, it’s not that hard, for an example, go look at the
testing framework for
Genx, it’s called
tgx and it gets run every time you type make.
If you’re a Software Development Manager, ask your engineers if they’re using TDD, and if they’re not, make them start.
And if you’re a CIO, ask your development people if they’re using TDD internally, and if they’re not, go order some copies of Kent Beck’s Test Driven Development: By Example and hand them out and tell them to get with the program. Anything less would be unprofessional.
