Acceptance test-driven development
Acceptance test-driven development (ATDD) is a practice in which the customer, developer and tester agree on the acceptance tests for a piece of work before any code is written, and the developer then builds until those tests pass. The tests are the acceptance criteria in executable form, so whether the work is finished is settled by running them rather than by discussion.
The longer version
The cycle begins with a conversation over a user story or requirement. The three roles write the acceptance criteria as concrete tests: inputs, actions and expected results, specific enough to automate. The tests are automated and run, and they fail, because the feature does not exist. The developer implements, using unit-level test-driven development or not, until the acceptance tests pass. The work is then accepted by the same tests that were agreed at the start, which removes the end-of-sprint argument about whether the story matched what was asked.
Behavior-driven development is the nearest neighbor and grew out of the same idea. Both write acceptance-level tests first with the whole team. BDD adds a specific form, the Given/When/Then scenario written in a domain language, and tooling that binds it to code; ATDD is the broader practice and does not prescribe a syntax, so its tests can be tables, plain test cases or scripts. Test-driven development differs in scale: it is the developer's own cycle over single functions and classes, run many times inside one ATDD cycle rather than instead of it. User acceptance testing is different in timing: it happens after the work, by the customer, whereas ATDD moves the acceptance decision to before it.
The practice slips when the tests are written after the code, which turns them into a regression suite that confirms what was built rather than what was wanted. It slips when the customer role is absent and the developer writes the acceptance tests alone, because the tests then encode the developer's reading of the requirement, which is the ambiguity the practice exists to remove. And it slips when the tests are agreed but never automated, so the story is accepted by a manual pass that nobody repeats.
Common questions
What is the difference between ATDD and BDD?
Both write acceptance-level tests before implementation with product, development and testing together. Behavior-driven development prescribes the Given/When/Then scenario form and a domain language readable by non-developers, with tooling to run it. Acceptance test-driven development is the broader practice and leaves the form of the tests open, so tables and conventional test cases qualify.
Who writes the acceptance tests in ATDD?
The customer or product owner, the developer and the tester write them together before coding starts. The customer supplies the examples that define acceptable, the tester adds the boundaries and failure cases, and the developer confirms each test can be automated. Tests written by the developer alone after the fact are a regression suite, not ATDD.
Is ATDD the same as user acceptance testing?
Acceptance test-driven development and user acceptance testing both concern whether the work is acceptable, but at opposite ends. UAT happens after implementation, performed by the customer or their representatives on a finished build. ATDD fixes the acceptance tests before implementation, so the work is built to pass tests that were agreed up front.
What is the difference between ATDD and TDD?
TDD operates on one function or class at a time: the developer writes a small test that fails, writes enough code to pass it, and tidies up before the next. Acceptance test-driven development works on a whole story, with the customer and tester in the room, and its tests define when the story is accepted. A developer runs many TDD cycles inside one ATDD cycle, while the acceptance tests stay red until the feature is complete.
What does an ATDD acceptance test look like?
A concrete example tied to one story, expressed in the domain's own terms: a table of inputs and expected outputs, a scripted sequence of actions and results, or a plain-language scenario if the team prefers that form. Each test names what the customer will accept, is specific enough to automate, and fails before the feature exists. A test that only a developer can read has drifted from the practice.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.