Similar to test-driven development, Acceptance Test Driven Development (ATDD) requires team members with different perspectives (customer, development, testing) that are able to cooperate to write acceptance tests in advance of implementing the corresponding functionality.
The collaborative discussions that happen to generate the acceptance test are 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).
These different terms exist to stress some differences in approach that lead to close results.
Just as TDD results in applications designed to be easier to unit test, ATDD favors the creation of interfaces specific to functional testing.
Even more than the use of automated acceptance tests, this practice is heavily associated with the use of specific tools such as Cucumber or others.
On the other hand, one major risk, is that the tool chosen will block, instead of advance the main purpose of this practice: making conversation between developers easier and facilitating product owners about product requirements. To meet product owners’ needs, tools should be adapted.