Acceptance test-driven development
 | This article, Acceptance test-driven development, has recently been created via the Articles for creation process. Please check to see if the reviewer has accidentally left this template after accepting the draft and take appropriate action as necessary.
Reviewer tools: Inform author |
Introduction
Acceptance Test-Driven Development (ATDD) helps with communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as Specification by Example (SPE) [link to the page] , Behavior Driven Development (BDD) [Chelimsky01,, example-driven development (EDD) x [Marick01], behavior-driven development (BDD) by Dan North], Story Test-Driven Development (SDD) by Joshua Kerievsky of Industrial Logic [Kerievsky01],Executable Acceptance Test-Driven Development (EATDD) [EATDD01]. All these processes aid developers and testers in understanding the customer’s needs prior to implementation and customers being able to converse in their own domain language.
Definition
Acceptance tests are from the user’s point of view – the external view of the system. They examine externally visible effects, such as specifying the correct output of a system given a particular input. Acceptance tests can verify how the state of something changes, such as an order that goes from “paid” to “shipped”. They also can check the interactions with interfaces of other systems, such as shared databases or web services.
In general, they are implementation independent, although automation of them may not be.