ATDD

Differences from TDD

While TDD drives a developer's code design, ATDD aims to align the entire team's understanding of business requirements. Just as TDD follows a "RED → GREEN → Refactor" cycle, ATDD has its own distinct cycle:

1. Discuss: The product owner, developers, and QA discuss requirements and agree on acceptance criteria through concrete examples.
2. Distill: The agreed-upon criteria are translated into a structured format such as Given-When-Then.
3. Develop: Acceptance tests are automated, and implementation begins with the tests in a RED state.
4. Demo: Once the tests turn GREEN, the results are demonstrated to stakeholders.

Three Amigos

At the heart of ATDD is the "Three Amigos" session held before implementation. By discussing acceptance criteria from three perspectives — business, development, and testing — ambiguities and misalignments in the specification are resolved early. This is highly effective in preventing rework caused by misunderstandings that only surface after coding has begun.

Barriers to Adoption

Because ATDD affects the entire development process, it cannot be started simply by introducing a tool. The whole team needs to become comfortable with writing acceptance criteria, and active involvement from the product owner is essential. A practical approach is to start with a single user story, experience the benefits firsthand, and then gradually expand the scope.