There has been some buzz around the office recently about getting some TDD training. I figured I could drop my 2¢ in with an example of how it helps me. It’s not about bug-free code. Or even faster coding. To me, it’s about reducing rework.

I have a dirty secret. I’m not always awesome. On occasion, I’ve been known to write a bug. Not often! Most of the code I write mostly works, so I’ve got that going for me.

When I had to rewrite a subsystem of our application because of a drastic change in the requirements, I wasn’t worried. I had the parts that needed changing isolated and I had an interface that would work. I just needed to gut some classes and start over. And write some tests showing the behavior I wanted that section to have. For those playing the home game, this is related to the “London School” of TDD and BDD.

It worked flawlessly. Until our test lead thought of corner cases I had not considered. That’s his job, and he’s good at it. But here is where the awesome came in…

I added some test cases to some itty bitty logic classes deep in the code to handle those new behaviors. Then I made ’em pass. Easy.

The best part is I knew I did’t break the cases I had already covered. That means this bug won’t cause more bugs.

Contrast this with a project I was working on a bit over a year ago. It was very hard to wrap test cases around it because of how I had written the interface to the UI. We played ‘whack-a-mole’ with the same few issues for a few iterations.

And that’s what it’s about. I don’t want to fix code that was working. I want to write code for features and cases that aren’t already there.