TDD — The Actual Cycle
Common questions I hear from developers when they are first starting out with TDD are:
“How do I know which scenario to work on first?”
And
“How do I know when I’m done?”
After reading “Growing Object-Oriented Software, Guided By Tests” by Nat Pryce and Steve Freeman it became clear that the usual Test Driven Development (TDD) process diagram (Fig 1) did not provide the framework for developers to get a clear answer to these two questions.
This overly simplistic view of the TDD process creates the following problems:
“Start” — where, with what?
“Write a Failing Test” — Just unit tests?
“Stop” — When? I don’t want to write more code than necessary!
It also seems to imply that the burden of figuring out what to work on first and how it should be broken up in order to TDD it effectively sits squarely on the developer alone. This is simply not true.
The solution provided by the authors of the book is quite simple and that is that you need to write a failing acceptance test before starting (Fig 2.)
We simply need to write a failing acceptance test which describes the behavior expected from, and therefor the scope of, the increment being built. You must not write any more unit tests and code than necessary to make the acceptance test pass. You must not write any more acceptance tests than acceptance criteria defined on the story. The acceptance test is derived directly from the acceptance criteria of the user story.
The introduction of the acceptance test into the TDD cycle also creates an opportunity to broaden the responsibility for creating an environment conducive to the successful adoption of TDD. The process of story prioritization and refinement; and the prioritization and refinement of the associated acceptance criteria is a team effort. The entire team is therefore responsible for creating this TDD positive environment.
