Test Driven Development in Practice

I’ve been doing a lot of work recently on a new product and using a pure Test Driven Development (TDD) approach. This has been a chance to put TDD “under the microscope” and see how it fairs in real use, as compared with the hype people generate as they talk about it. It’s been unnerving.

Like any fairly experienced developer working in a familiar environment, I’m used to having a pretty good idea how long a particular task should take me. One of the reasons this is useful is if things start to take longer, I can evaluate why. Maybe my original understanding was faulty, or it could be that I’m just too tired and really should stop.

Test Driven Development has pushed me into unfamiliar territory. There are several observations I could make and discuss:

• Better class interfaces;
• Coupling between classes is lower;
• Significantly fewer bugs;
• Shorter bug resolution time; and
• More reusable (generic) classes.

Maybe in a later blog entry, I’ll go into some of these.

The one area I want to focus on here, though, is that of raw speed & pace.

I’ve found it faster to write classes with fully integrated tests than those without. It’s so simple it’s scary - when the tests all pass, move on to the next task.

It’s also faster to make heroic changes.

For example, I recently found that a Lexer class I was working on really needed a full internal StateMachine instead of the half baked job that was there.

So, I build a simple, standalone, state machine class with its own set of tests, and set aside a whole evening to make the changes to my lexer.

Based on my past experience, I expected the changeover to take four or five hours all up. After all, there are always niggly edge cases that need to be resolved when doing something this major - I was committing to change maybe a third of the existing code, much of it a rewrite.

How long did it actually take?

Under two hours.

It was so fast that I was sure I’d missed something - that there was a missing test case. But, I went over all the tests and couldn’t find any missing ones. I guess that took me 20 minutes or so - and it was still under two hours from my start time when I finished that review.

I’ve made extensive use of the new class over the past few weeks and it performs exactly as I would hope. So, I really didn’t miss anything.

I was keen on TDD before, but now I’m in danger of becoming a zealot.

When was the last time you finished a development task and have everything completely implemented and tested in under half the available time?

The only thing I’d do differently next time would be to use DUnit instead of rolling my own test framework.