Drifting Into Test-Driven Development

About two years ago I first read about Test-Driven Development on the c2 wiki. It’s a simple plan: before you write code, write the tests that will exercise it.

My thoughts: this is exactly backwards.

But I really liked the pages I read about automated testing and started putting that in practice almost immediately. Rather than sitting there and hitting reload and filling in forms and clicking buttons and waiting for pages and forgetting to check what happens when you leave half the form blank and... well, rather than all that error-prone tedium, I wrote code to test my code. And that’s great. It saves me from a lot of “oh yeah, I forgot that thing over there called this code” bugs.

I kept hearing about TDD, though. Books would mention it, blogs would tout it it. I guess it’s squirmed its way into my habits.

In the last few months of coding on NearbyGamers I’d hack at the models a bit, write some tests for them, and hey, as long as I’m writing tests, add some tests for the controller code I was about to build on top of that. And then maybe, after I implemented the basic feature, I’d write a test for an improvement and then tweak that code. In the last two weeks I’ve been writing code for the messages and forums and I just recognized that my tests have snuck in front of my code almost every time.

And it doesn’t feel backwards anymore. It just makes sense to think about my interface first, and to spend a minute pondering what sort of devious corner cases I can throw at it. I’m writing more tests, letting fewer bugs into production, and having more fun. I`ve broken the “Ehhh... it works, I’ll check it in and write some tests tomorrow” habit.

So this is my little bit of cheerleading for Test-Driven Development, a little more exposure for your unconscious mind to chew on.