Analogous to test-driven development, Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality. The collaborative discussions that occur to generate the acceptance test is often referred to as the three amigos, representing the three perspectives of customer (what problem are we trying to solve?), development (how might we solve this problem?), and testing (what about…).
These acceptance tests represent the user’s point of view and act as a form of requirements to describe how the system will function, as well as serve as a way of verifying that the system functions as intended. In some cases the team automates the acceptance tests.
Also Known As
ATDD may also be referred to as Story Test Driven Development (SDD), Specification by Example or Behavior Driven Development (BDD). These different terms exist to stress some differences in approach that lead to similar outcomes.
Expected Benefits
Just as TDD results in applications designed to be easier to unit test, ATDD favors the creation of interfaces specific to functional testing. (Testing through an application’s actual UI is considered less effective.)
Common Pitfalls
Even more than the use of automated acceptance tests, this practice is strongly associated with the use of specific tools such as Fit/FitNess, Cucumber or others.
One major risk, therefore, is that the tool chosen will hinder rather than advance the main purpose of this practice: facilitating conversation between developers and product owners about product requirements. Tools should be adapted to meet product owners’ needs rather than the other way around.
Origins
- 2003: Kent Beck briefly mentions ATDD in the book “Test Driven Development: By Example” but dismisses it as impractical
- 2003 to 2004: driven by the popularity of Fit/FitNesse ATDD becomes accepted practice in spite of Beck’s objections
