Acceptance Test-Driven Development (ATDD) defines acceptance tests for requirements prior to implementing those requirements. The acceptance tests represent the specific details of the capability that will be delivered. Defining these tests up-front gives a high confidence that the system will meet the expectations of the customer.
ATDD has been shown to have numerous benefits, including:
- Little room for miscommunication
- Workflows working the first time
- Getting business rules right
- Tighter cross-functional team integration
- Crisp visible story completion criteria
Who
There are three groups (the triad) involved in the practice:
- Customer. The customer group (requirements requestors). This group can include:
- Developer. The developer group (requirements implementers)
- Tester. The tester group (monitors implementations of requirements)
What
An approach where tests help specify the product/service. Automation is desirable for regression testing, but not required to implement the tests.
Inputs
Inputs to this practice include:
- Co-working relationship with the customer(s)
- Means of specifying acceptance tests that are easily read and understood by the customer as well as the developer
Approach
- Collaborate on ubiquitous language
- Develop examples, demos, prototypes, etc. to understand requirement
- Lead with “what would you want to see “
- Create scenarios (typically in the “Given-When-Then” format)
Tools and techniques for automation
- Gherkin (test syntax), Cucumber (Java and other languages), Specflow (C#)
- FIT (Framework for Integrated Test)
- FitNesse (using a wiki for using FIT)
Outputs
- Acceptance tests that are always as mature as the requirements
- Optional (but usually highly desirable): automated tests for scenarios.
When
ATDD starts when requirements are first being developed.
Outcomes
Fewer defects due to misunderstood requirements.
