Wednesday, November 30, 2005

Test Driven Development

I've spent the last week or so pairing with Robert Collins (Bazaar-NG, Squid). His solitary goal was to force feed me TDD whether I liked it or not. He wasn't interested in my concerns about whether or not TDD caused problems with design. He was deaf to my worries that the code we worked on wouldn't result in solid testing. Nope. Not Rob. "I'm not going to make you do this for the rest of your life, but you're going to do it this week."

I jumped in with the promise that this particular tunnel really did have an end. The worst that could happen was that I would have to load up on tests and rewrite the code so that it would be sufficiently flexible to evolve over its lifetime. The best that could happen is that I would have to swallow my pride and say that he was right.

I didn't start writing test cases for my code until about a year ago. There wasn't much point; anything that I could write a test case for, I could do more flexibly by hand. I just didn't like the idea of putting aside real code for the purpose of fake code with the sole purpose of making the real stuff do some functional equivilant of jumping jacks.

Somebody once pushed me to try using them anyways. He suggested. He prodded. He reminded. He pushed. He said something very similiar to what Rob did: "Do it for a week and then decide whether or not there's use".

So I tried it. When I found a bug in a program, I wrote a test case. If I wrote code that was too complicated to test by hand, I wrote a test case. I even write test cases when submitting code to someone else.

Test cases are more like jumping jacks than I realized. Each test case is like hopping for a jumping jack - a little bit of effort and no real movement. But when does a lot of jumping jacks, something magical happens. Bodies strengthen. Health improves. Sickness is fought off more easily. Lots of good things come from jumping jacks.

The exact same thing happens with test cases. Your codebase, with a lot of good test cases, becomes strong. A small change over here won't cause subtle breakage somewhere else. If it does, your test cases will scream -- loudly and clearly -- that something has gone terribly, terribly wrong.

Test Driven development is more of the same thing with one notable exception: Write test cases first and code second. After all, isn't it better to do a few jumping jacks at a time when you're still young and healthy... or after you've already gotten fat and lazy?

Oh, I almost forgot to mention. The same person that turned me onto Test Driven Development is the same Rob Collins that got me into testing code in the first place.

Thanks Rob.