Test Driven or Test First?

I recently got into a discussion with Cobbie Behrend, following on from some comments I’d made about test-driven development. I’d said that I rarely do test-first, but I often do test-driven coding.

Cobbie pushed me to distinguish between them, particularly in light of references on the Object Mentor site, the C2 wiki, and other sites, which seem to equate the two.

I disagree—test-first is different than test-driven development.

For me, test-driven development is an important way of thinking about coding. It’s about using tests to gain perspective on your design and implementation. You listen to what the tests are telling you, and alter to code accordingly. Finding it hard to test something in isolation? Refactor your code to reduce coupling. Is it impossible to mock out a particular subsystem? Look at adding facades or interfaces to make the separation cleaner. Tests drive the design, and tests verify the implementation.

Test-first development takes this a step further. In test-first, you never write a line of production code until you first have a failing test that will be "fixed" by the code you write. Want to write a new class? First write a test that instantiates it, watch the test fail, and then implement the class body to fix the broken test.

Test-first development is a subclass of test-driven development. It has every benefit of test-driven development, and then adds a ritual component of testing and coding in a certain order. The intent of the ritual is to ensure that tests are always produced.

For me, test-driven development is an essential part of coding. Test-first coding, however, often strikes me as unnecessarily high-church. So I distinguish the two, in the same way that I distinguish agile methods from eXtreme Programming. Test-driven is an important, almost universal practice. Test-first is a particular implementation, and it isn’t always applicable.

I don’t know if this helps Cobbie in his search for meaning, though…