Acceptance test-driven development ATDD) is a formalized development framework that defines how the product should behave through written acceptance tests. These are agreed upon before any development takes place, driving the product development and optimization.
For the ATDD methodology to work, product owners, developers, and test engineers must come together at the very beginning of the project to turn the product objectives into clear, comprehensive descriptions of what behavior is expected in every situation.
The descriptions are written in plain language, with an agreed, shared framework to align the acceptance tests more closely with user experience.
The developers write the software to pass the acceptance tests and the test engineers use the acceptance tests to verify that the software is working correctly. The strength of ATDD is in the clarity of pass/fail acceptance tests that define success, which also allows for testing automation.
The ATDD framework can vary from team to team, but in agile development, it will often follow the given, when, then model, to match the as a, I want, so that user story model.
As an example, the user story may go
As an existing customer
I want to review my recent purchases
So that I can reorder when necessary.
One corresponding acceptance test might be
Given the customer is logged in and has made previous purchases
When they navigate to the home screen
Then their most recent purchase is available as a link for more recent purchases
And a quick reorder button is shown to allow a one-click reorder.
As agile teams iterate through the discussion, distillation, development, and demo cycles to meet the expectations given by user stories, the discipline of defining the success markers in the discussion phase keeps the whole agile team on board and focused throughout development.
Agile software may change drastically throughout a product life cycle. ATDD and the associated automated tests ensure new iterations don’t break older code.
Both BDD (Behavioral-Driven Development) and ATDD evolved from TDD (Test-Driven Development).
In TDD testing, engineers test after development has started according to their understanding of the objectives. Both BDD and BTDD flip that on its head, involving product managers and developers alongside test engineers before development — to collaborate on acceptable behavior according to the objectives.
TDD focuses on getting correct outputs according to the inputs to smaller software components. Both BDD and ATDD concentrate on the software system’s acceptable behavior from the end-user’s standpoint. BDD uses the acceptance test writing phase to help developers and test engineers understand the behavior. ATDD seeks to fully define that expected behavior in the form of acceptance tests so developers and test engineers can work towards something more concrete and automate as much of the testing as possible.