{"id":5003368,"date":"2015-12-17T00:26:39","date_gmt":"2015-12-17T00:26:39","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&p=5003368"},"modified":"2022-08-29T14:42:14","modified_gmt":"2022-08-29T21:42:14","slug":"atdd","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/atdd\/","title":{"rendered":"Acceptance Test Driven Development (ATDD)"},"content":{"rendered":"
\n
\n

Analogous to\u00a0test-driven development<\/a>,\u00a0Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write\u00a0acceptance tests<\/a>\u00a0in advance of implementing the corresponding functionality. \u00a0The collaborative discussions that occur to generate the acceptance test is often referred to as the\u00a0three amigos<\/a>, representing the three perspectives of customer (what problem are we trying to solve?), development (how might we solve this problem?), and testing (what about\u2026).<\/p>\n

These acceptance tests represent the user\u2019s 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.<\/p>\n<\/div>\n<\/div>\n

Also Known As<\/h2>\n
\n
\n

ATDD may also be referred to as Story Test Driven Development (SDD), Specification by Example or\u00a0Behavior Driven Development (BDD)<\/a>. \u00a0These different terms exist to stress some differences in approach that lead to similar outcomes.<\/p>\n<\/div>\n<\/div>\n

Expected Benefits<\/h2>\n
\n
\n

Just as TDD results in applications designed to be easier to\u00a0unit test<\/a>, ATDD favors the creation of interfaces specific to functional testing. (Testing through an application\u2019s actual UI is considered less effective.)<\/p>\n<\/div>\n<\/div>\n

Common Pitfalls<\/h2>\n
\n
\n

Even more than the use of automated acceptance tests, this practice is strongly associated with the use of specific tools such as\u00a0Fit<\/a>\/FitNess<\/a>,\u00a0Cucumber<\/a>\u00a0or others.<\/p>\n

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\u2019 needs rather than the other way around.<\/p>\n<\/div>\n<\/div>\n

Origins<\/h2>\n
\n
\n