Acceptance test-driven development

ATDD places a collaboratively agreed acceptance test before the production code that must satisfy it. The test usually describes a complete behavior at the system boundary rather than an internal class or function, making it a form of requirements specification as well as a test.¹

A business representative supplies the intended outcome, a tester examines risks and observable conditions, and a developer considers feasibility and design. This conversation is sometimes called the “three amigos” meeting. The resulting examples clarify ambiguous business rules, expose missing cases, and establish a shared definition of done. Unlike a demonstration prepared after coding, an acceptance test is intended to guide scope and implementation from the beginning.

ATDD is related to, but not identical with, test-driven development (TDD). TDD normally drives small units of design through programmer-written unit tests; ATDD drives externally visible behavior through examples agreed with stakeholders. The two practices can be used together.

The usual ATDD workflow is discuss, specify, automate, implement, and review. A team first converts a requirement into a small set of concrete examples, then makes those examples executable where practical, writes the minimum implementation needed to pass them, and refines both code and examples as understanding improves.

Scenarios are often expressed with Given–When–Then: a Given clause establishes context, When describes an action, and Then states an observable result. The syntax is associated with Gherkin and tools such as Cucumber, but ATDD does not require a particular tool or language.² Examples should use domain vocabulary, avoid implementation details, and remain small enough for a stakeholder to validate.

Passing scenarios commonly become part of continuous integration. A failing scenario can indicate a defect, a changed requirement, unsuitable test data, or a brittle interface; teams must investigate rather than treating every failure as proof that the implementation alone is wrong.

ATDD reduces misunderstanding by making acceptance conditions visible before work is considered complete. Its most durable artifact is often the conversation and the resulting examples, which can serve as living documentation for product behavior.¹ Early examples may also reveal contradictory requirements, unavailable data, authorization gaps, or edge cases that a conventional requirements document leaves implicit.

The method does not guarantee correct requirements. Examples can encode the wrong policy, omit rare but consequential states, or become misleading when nobody maintains them. End-to-end scenarios may be slow and costly to diagnose, especially when they depend on external services or unstable interfaces. Teams therefore commonly combine a smaller set of business-facing acceptance tests with unit, component, security, performance, and exploratory testing.

ATDD is most effective when domain experts can participate regularly and when the organization allows requirements to be clarified during development. It is less useful as a ceremony in which technical staff write scripts after decisions have already been made.

ATDD can be practiced without automating every acceptance example. A paper checklist, a structured example table, or a manually executed scenario can still drive development, although automation improves repeatability and regression detection when the behavior is stable.

A less obvious benefit is its use as a boundary-design technique. Asking what a customer can observe often exposes unclear APIs, hidden state transitions, localization assumptions, time-zone rules, and permissions before those concerns are buried in implementation. Examples can also be parameterized into decision tables when behavior depends on several combinations of inputs.

ATDD is frequently discussed alongside behavior-driven development and Specification by Example. The practices overlap in their emphasis on concrete examples and shared language, but names vary by community: BDD often emphasizes the vocabulary and behavior narrative, while ATDD emphasizes acceptance criteria as the driver of development.³ Neither practice replaces professional judgment, accessibility review, or testing for qualities that a single business scenario cannot express.

Acceptance test

A test that evaluates whether a system satisfies agreed business or user requirements, usually at a boundary visible to stakeholders.

ATDD

The abbreviation for acceptance test-driven development.

Given–When–Then

A scenario pattern describing initial context, an action or event, and the expected observable outcome.

Gherkin

A structured, human-readable language commonly used to write executable behavior scenarios.

Three amigos

A collaborative discussion among business or product, testing, and development perspectives before implementation.