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:
- Write an automated test for a new bit of functionality, run it and watch it fail (“red”)
- Write enough code to make the test (and all the other tests) pass (“green”)
- Clean up any messes you’ve made while keeping all the tests passing (“refactor”)
- 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.