One of the things that I love about the blogosphere is that it allows everyone to make up new definitions for established practices. As a perfect example have a look at John Wood’s “The Inefficiency of Test Driven Development”.
So what does this have to do with Test Driven Development? Effectively, with only a little hint, I'm determining the requirements based on the reaction to the tests. The tests are driving my efforts to meet her requirements. And this is actually a lot like how TDD works.
With all due respect to John this has absolutely and positively nothing to do with test driven development. If your trying to use TDD to gather your requirements its no wonder your not a fan. Test driven development is not a requirements gathering tool. Believe it or not the people who started the whole agile movement recognized what John is talking about. They recognized that the interactions between people was extremely important. They recognized that the business experts should be a core member of the team and that the interactions between the business experts and programmers was of crucial importance. They even put it at the top of their list of things to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
How is it that we’ve fallen so far from what agile and test driven development are about? Perhaps its the fact that the name doesn’t really suite. Perhaps people take it literally and assume that test driven development means that you shouldn’t talk with anyone, just let your tests drive all aspects of your development. Instead of having business prioritize and develop stories we should just dive right into the test driven development process and have the test drive everything. Forget having a vision, just start coding and let the requirements show themselves.
Anyway since I don’t think the point of John’s post was to redefine TDD as a requirements gathering tool I think I’ll stop there. Before I sign off though let me remind you that TDD is about design. It’s not about gathering requirements, its not about defining a contract of intended behaviour, its about following a process that forces you to think about the design of your software every step of the way. If you don’t value design don’t do TDD. If you think TDD is a requirements tool don’t use TDD.