I suppose, if one gets much ego-boo from showing off one’s debugging chops, a test-first or test-driven style might be a problem – because you don’t have much debugging to do.

(Tip o’ the hat to Liz Keough.)

Ever since Kent Beck first came out with his book “Test Driven Development: By Example” in 2003, I’ve been using his brilliantly simple technique to create working software:

1. Write an automated test for a new bit of functionality, run it and watch it fail (“red”)
2. Write enough code to make the test (and all the other tests) pass (“green”)
3. Clean up any messes you’ve made while keeping all the tests passing (“refactor”)
4. Repeat steps 1-3 until there’s no more functionality to add

Sometimes, I find myself unable to figure out a way to get through step 1. Maybe I can’t think of how to test the new functionality. More likely, I can’t think of a way to test the new functionality given the toolset I have available to me. (Not all programming languages come with good automated testing support, after all.)

I don’t let the lack of tool support keep me from adding functionality to whatever it is I’m coding. On the other hand, any code I write that’s not covered by automated tests invariably has more bugs escape my desk than the code I write that is covered by automated tests.

And that, in a nutshell, is why I code test-first.