What is Acceptance Test-Driven Development (ATDD)?

Acceptance Test-Driven Development (ATDD) is a collaborative practice where the team defines acceptance tests for a feature, agreed on by business, development, and testing, before development starts, so everyone shares a concrete understanding of "done" and builds to those tests.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

IN DEPTH

In depth.

ATDD shifts the conversation about requirements to before coding. The "three amigos" (typically a business/product representative, a developer, and a tester) collaborate to write acceptance tests that express the expected behavior in concrete, agreed terms. Development then aims to make those acceptance tests pass, and the tests double as living documentation and a shared definition of done.

Its main value is shared understanding and fewer misinterpreted requirements: by hashing out concrete examples up front, the team surfaces ambiguities and disagreements before expensive code is written. The acceptance tests are usually automated so they can verify the feature continuously.

ATDD is often confused with TDD and BDD. TDD is a developer practice operating at the unit level (write a failing unit test, make it pass, refactor). BDD focuses on describing behavior in natural language (Given-When-Then) to improve communication. ATDD centers on collaboratively defining acceptance criteria as tests before development. They overlap, BDD is frequently used to express ATDD acceptance tests, but they differ in scope and emphasis: ATDD is about agreeing acceptance up front; TDD is about unit-level design; BDD is about a shared behavioral language.

WHY IT MATTERS

Why interviewers ask about this.

ATDD vs TDD vs BDD is a common interview discriminator. Explaining ATDD as collaborative, pre-development acceptance definition, and how it differs from unit-level TDD and language-focused BDD, shows you understand agile quality practices beyond buzzwords.

EXAMPLE

Example scenario.

Before building a discount feature, the three amigos meet and agree on acceptance tests: "a 10% coupon on a $50 order yields $45," "an expired coupon is rejected with a clear message," and so on. Developers build until those automated acceptance tests pass, and a previously hidden disagreement about stacking coupons is resolved before any code is written.

TIP

Interview tip.

Define ATDD as collaboratively defining automated acceptance tests before development to align business, dev, and test on "done." Distinguish it from TDD (developer, unit-level) and BDD (natural-language behavior). Mention the three amigos and that BDD is often used to write ATDD tests.

FAQ

Frequently asked questions.

What is the difference between ATDD and TDD?

TDD is a developer practice at the unit level: write a failing unit test, write code to pass it, refactor. ATDD operates at the acceptance level and is collaborative: the team agrees automated acceptance tests for a feature before development. TDD drives code design; ATDD drives shared understanding of requirements.

What is the difference between ATDD and BDD?

They overlap heavily. BDD emphasizes describing behavior in natural language (Given-When-Then) to improve communication. ATDD emphasizes collaboratively defining acceptance tests before development. In practice, teams often use BDD-style syntax to express ATDD acceptance tests, so the two are complementary.