The components of software processes work together in important and sometimes unrecognized ways. The removal of one of those components will affect the others. In this article, which originally appeared in the August 2010 issue of the Iterations eNewsletter, Jennitta Andrea takes a look at the value of acceptance test-driven development and the costs of making it an optional practice.
As a practitioner, I prefer to define agile by its visible outcome, rather than focusing on the collection of practices performed by a team. I define agile as: "delivering running tested features to the user community on a regular basis to maximize business value and to respond to timely feedback with strategic product adaptation."  I believe it's healthy for different agile projects to make different decisions about their practices, as long as the outcome is achieved and sustained. Successful projects understand that project context (criticality, complexity, duration, team composition, etc.) is key to making good decisions about their agile process.
That said, it concerns me that far too many teams treat the acceptance test-driven development (ATDD) practice as optional.
What Is ATDD?
ATDD (a.k.a. story test-driven development, functional test-driven development, behavior-driven development, etc.) is the practice of expressing functional story requirements as concrete examples or expectations prior to story development. During story development, a collaborative workflow occurs in which: examples are written and then automated; granular automated unit tests are developed; and the system code is written and integrated with the rest of the running, tested software. The story is "done"—deemed ready for exploratory and other testing—when these scope-defining automated checks pass. 
Why Should We Practice ATDD?
Software processes are like an ecosystem; all of the components—activities, practices, roles, workflows, tempo, tools, and work products—depend upon and enable each other in complex and unexpected ways.
Trustworthy specifications: ATDD requirements specifications are trusted because they are concrete, thus bringing areas of ambiguity and inconsistency to light very early. They are living (automated) documents that will not get out of sync with the code. Whenever the code is changed, immediate feedback is provided about mismatches between the two. This level of trust exists for the lifetime of the system, facilitating the transition to operational support for maintenance and enhancements.
Short iterations: Given the above definition, the key to an agile project is incrementally building the system, feature by feature. Everything-requirements, design, development, integration, testing, and review-is condensed in order to fit an entire cycle into a short, fixed-sized iteration (typically two weeks). ATDD helps the team maintain a concrete, clear focus and provides an unambiguous definition of what "done" means for each piece of work in the iteration.
Incremental development: Working incrementally means different people will revisit and integrate the same code many times. This approach is not practical unless there is a safety net of automated checks to ensure unintended side effects have not been introduced. ATDD builds such a safety net at both the business- and technology-facing levels. 
Enriched tester role: In the early days of agile, it was thought that ATDD would make testers obsolete. Early agile projects found out the hard way that the tester role is needed more than ever. Ironically ATDD makes the tester role much more enriched and valuable. Automated examples and unit tests take care of the "checking," guaranteeing a stable system for the testers to perform their creative, skilled, and value-added work of "testing." 
Highly testable system: ATDD produces a highly testable system. Having examples and unit tests drive development ensures that the system can be accessed and validated from any possible angle, facilitating future automation as well as manual testing and operational diagnosis.