03.08.2026

ATDD — Acceptance Test Driven Development

Движущая сила: критерии приёмки (acceptance criteria), выраженные как автоматические тесты до реализации.

Уровень применения: команда (приёмочное тестирование) и код.

Статус: устоявшийся (корни в XP, конец 1990-х — начало 2000-х; систематизирован в работах Лизы Криспин, Дэна Норта, Гойко Аджича; эволюционировал в BDD и Specification by Example).

Не путать с: TDD (инженерная микро-практика на уровне юнитов) и BDD (поведение и общий язык в сценариях Given-When-Then) — подробное разведение ниже.

Общее

Acceptance Test Driven Development (ATDD) — методология разработки, при которой для каждой пользовательской функциональности сначала формулируются критерии приёмки, затем они превращаются в автоматические приёмочные тесты, и лишь потом пишется реализация. Тесты здесь — не артефакт постфактум и не инструмент разработчика (как в TDD), а общая спецификация: единый артефакт, который одновременно фиксирует, что именно строится, проверяет результат и служит документацией. Ключевая идея: если бизнес и команда не договорились о критериях приёмки до начала кодирования, то и код, и тесты пишутся вслепую.

ATDD вырос из методологии Extreme Programming (XP), где «приёмочное тестирование силами заказчика» входило в исходный набор практик. Раннее оформление подхода связано с именами Лизы Криспин (Lisa Crispin) и Типа Хауса (Tip House) — книга Testing Extreme Programming (2003), где приёмочные тесты впервые описаны как полноправная часть процесса, а не проверка постфактум. Дэн Норт (Dan North) в середине 2000-х ввёл само сокращение ATDD и показал, что проблема приёмочного тестирования — не в инструменте, а в коммуникации между бизнесом и разработкой; из этой работы напрямую вырос BDD. Гойко Аджич (Gojko Adžić) в книге Specification by Example (2011) обобщил опыт десятков команд и сформулировал подход как набор паттернов: совместное написание спецификаций, использование примеров вместо абстрактных требований, исполнение спецификаций как тестов и живая документация.

Принципиальное отличие ATDD от остальных «*DD» в этой серии — его движущая сила. Если в TDD дизайн кода направляют юнит-тесты, в DDD — модель предметной области, в FDD — процесс доставки функции, то в ATDD драйвером выступает договорённость о приёмке: конкретные, проверяемые примеры того, когда работа считается выполненной. ATDD живёт на уровне выше TDD: он задаёт рамку «что и зачем мы строим», тогда как TDD страхует «как именно написан код». В зрелой кодовой базе эти подходы дополняют друг друга: ATDD фиксирует поведение фичи целиком, TDD страхует отдельные единицы внутри неё.

Важно сразу развести три родственных подхода — TDD, ATDD и BDD, — потому что именно их смешение порождает больше всего путаницы. Все три «пишут тесты до кода», но на разных уровнях и с разными целями:

  • TDD — микро-практика одного разработчика; цикл Red-Green-Refactor; уровень — единицы кода; драйвер — дизайн кода.
  • ATDD — командная практика; уровень — пользовательская функциональность (фича); драйвер — критерии приёмки; формат — произвольный (таблицы, примеры, сценарии), лишь бы исполняемый.
  • BDD — эволюция ATDD с акцентом на общий язык (ubiquitous language) и формат Given-When-Then; фокус смещён с тестирования на диалог бизнеса и разработки через поведение.

Развёрнутое сравнение — в разделе «Связанные подходы».

Ключевые принципы

ATDD — это не «писать приёмочные тесты» (это любая разработка с QA), а набор принципов, которые в совокупности меняют то, как требования становятся кодом. Ниже — формулировка каждого с пояснением, какую конкретную проблему он решает.

Критерии приёмки → тесты до кода. Приёмочные тесты пишутся до начала реализации, на этапе планирования фичи, а не после. Проблема: тесты, написанные постфактум, подтверждают то, что уже сделано, а не то, что предполагалось; разрыв между «что просили» и «что построили» обнаруживается поздно и дорого. Тест, написанный первым, фиксирует договорённость и делает её исполняемой — реализация проверяется против неё, а не наоборот.

Совместное написание (триадой). Приёмочные тесты формулируются не одним разработчиком и не одним QA, а всеми заинтересованными сторонами — разработчиками, тестировщиками, Product Owner-ом/аналитиком, часто и заказчиком. Проблема: требования, спущенные «сверху» в виде текстового документа, трактуются каждой стороной по-своему (классический «телефонный эффект»); совместное написание примеров вынуждает разобрать неоднозначности немедленно, пока они не превратились в код. Это та самая практика, которую Аджич назвал collaborative authoring — и которую BDD формализовал как Three Amigos (разработчик + тестировщик + аналик).

Примеры вместо абстрактных требований. Спецификация строится на конкретных примерах входных данных и ожидаемых результатов, а не на формулировках вроде «система должна корректно обрабатывать заказы». Проблема: абстрактные требования допускают десятки трактовок; пример «заказ на три позиции со скидкой 10% и купцом 500 ₽ должен вернуть итог 1850 ₽» однозначен и сразу превращается в тест. Это ядро подхода Specification by Example.

Автоматизация приёмочных тестов. Примеры оформляются так, чтобы их можно было запустить автоматически против системы, без ручных шагов. Проблема: ручное приёмочное тестирование медленное, неповторяемое и быстро отстаёт от кода; автоматизация делает спецификацию живой — она либо зелёная (соответствует коду), либо красная (расхождение), и этот статус проверяется на каждой сборке.

Живая спецификация (living documentation). Набор приёмочных тестов рассматривается как документация, которая не может устареть: если тест зелёный, он актуален. Проблема: статичная документация (Word, Confluence) рассинхронизируется с кодом за месяцы и становится источником дезинформации; исполняемая спецификация обновляется вместе с кодом и всегда отражает действительное поведение системы.

Shift-left приёмки. Момент, когда команда понимает «фича принята», смещается с финального ручного тестирования перед релизом на этап планирования. Проблема: приёмка «в конце» — это обнаружение недопонимания тогда, когда исправлять дороже всего (переписана целая фича); приёмка «в начале» (через совместно написанные тесты) ловит недопонимание до того, как написана первая строка кода. Подробнее о сдвиге тестирования влево — во введении в тестирование.

Принципы — система, а не меню. Тесты до кода без совместного написания дают «приёмочные тесты глазами одного разработчика» — то же самое недопонимание, только исполнимое. Совместное написание без автоматизации даёт стопку примеров, которые никто не запускает и которые устаревают за спринт. Автоматизация без примеров-спецификаций даёт набор e2e-тестов, которые что-то проверяют, но не служат документацией. Частичное внедрение создаёт «ATDD-theatre» — формальные приёмочные тесты без эффекта раннего консенсуса; полное — даёт именно тот сдвиг, ради которого методология и создавалась.

Как это работает

ATDD оперирует коротким циклом из четырёх фаз, повторяемым на каждой фиче. Ниже — механика.

Цикл ATDD: обсуди → дистиллируй → разработай → продемонстрируй

Фаза Что происходит Кто участвует Выход
Обсуди (Discuss) Команда и заказчик разбирают фичу, выделяют ключевые примеры, находят неоднозначности PO/аналитик, разработчики, QA, заказчик Набор примеров в свободной форме
Дистиллируй (Distil) Примеры превращаются в формализованные приёмочные тесты (таблицы, сценарии) Разработчики + QA (часто с PO) Исполняемые приёмочные тесты, красные
Разработай (Develop) Пишется реализация; внутри — TDD на уровне юнитов; приёмочные тесты постепенно зеленеют Разработчики Работающая фича + зелёная приёмочная спецификация
Продемонстрируй (Demonstrate) Зелёные приёмочные тесты показываются заказчику как доказательство выполнения договорённостей Вся команда + заказчик Подтверждённая приёмка

Первые две фазы — это инвестиция в раннюю договорённость; они занимают часы или день, но предотвращают недели переделок. Третья фаза — собственно кодирование. Четвёртая — момент, когда заказчик видит не демо «на честном слове», а исполненную спецификацию.

Форма приёмочного теста

В отличие от BDD, который фиксирует формат Given-When-Then, ATDD не предписывает конкретного синтаксиса. Допустима любая форма, лишь бы она была однозначной и исполняемой. Исторически сложилось несколько стилей:

  • Таблицы решений (Decision Tables) — набор «вход → ожидаемый выход» в табличном виде; классика, идущая от Fit/FitNesse.
  • Сценарии Given-When-Then — формат, который позже стал ассоциироваться с BDD, но исторически вырос из ATDD.
  • Ключевые слова на естественном языке (Robot Framework) — табличный DSL поверх человекочитаемого синтаксиса.

Мини-пример

Фича: «расчёт итога заказа со скидкой и купоном». На фазе «Обсуди» команда с PO договаривается о примерах:

Сумма позиций Скидка Купон Ожидаемый итог
1000 ₽ 10% 0 ₽ 900 ₽
2000 ₽ 0% 500 ₽ 1500 ₽
2000 ₽ 10% 500 ₽ 1300 ₽

На фазе «Дистиллируй» эта таблица оформляется как исполняемый тест (в FitNesse — через fixture-класс; в Robot Framework — через ключевое слово; в SpecFlow/Cucumber — через сценарий). Тест запускается — он красный (реализации нет). На фазе «Разработай» пишется реализация, внутри неё — TDD-циклы на юнит-уровне; приёмочный тест постепенно зеленеет. На фазе «Продемонстрируй» зелёная таблица показывается заказчику.

Суть цикла: каждый пример — это одновременно требование, тест и пункт документации. Их совокупность и есть спецификация фичи.

Инструменты

Инструмент Происхождение Подход
Fit (Framework for Integrated Tests) Ward Cunningham, 2002 Таблицы в HTML, fixture-классы на Java/.NET; первый массовый инструмент ATDD
FitNesse Object Mentor, 2005 Wiki-надстройка над Fit; таблицы пишутся и запускаются прямо в вики
SpecFlow 2010-е .NET-порт Cucumber; сценарии Given-When-Then привязываются к шагам на C#
Robot Framework Pekka Laukkanen / Nokia, 2008 Табличный DSL на ключевых словах; поддерживает разные языки через библиотеки
Concord (Walmart), Gauge (ThoughtWorks) 2010-е Современные варианты: спецификации в Markdown/HTML, интеграция с CI

Выбор инструмента вторичен по отношению к принципу: если команда совместно пишет примеры и автоматизирует их, ATDD работает; если нет — лучший инструмент не поможет. Подробно о месте приёмочного тестирования в общей картине качества — в материале acceptance testing.

Влияние на команду и процесс

ATDD часто обсуждают как «тестовую практику». Это сужение: устойчивый эффект возникает только тогда, когда приёмочные тесты встроены в командный процесс и ролевую структуру. Ниже — что именно меняется. Этот блок адресован прежде всего руководителям.

Product Owner и аналитик как авторы спецификации. В классическом процессе PO пишет пользовательские истории и «спихивает» их разработке; приёмка происходит в конце. В ATDD PO/аналитик — соавтор исполняемой спецификации: он участвует в фазе «Обсуди», приводит примеры, отвечает на вопросы разработчиков прямо во время написания тестов. Это меняет нагрузку: работа PO смещается с «написания историй» на «ведения диалога через примеры», и без готовности к этой роли ATDD не взлетает.

Definition of Ready и Definition of Done. ATDD органично встраивается в эти артефакты Agile/Scrum. В DoR появляется пункт «есть совместно написанные приёмочные тесты» (фича не берётся в спринт без них). В DoD — «все приёмочные тесты зелёные» (фича не считается готовой с красной спецификацией). Это превращает ATDD из «хорошей практики» в формальный gate процесса, что критично для устойчивости.

Планирование спринта через готовые спецификации. Когда приёмочные тесты написаны на фазе планирования, оценка фичи становится точнее: команда оценивает не абстрактную историю, а конкретный набор примеров и видно объём работы. Это снижает разброс оценок и уменьшает количество «сюрпризов» посреди спринта. Обратная сторона — фаза планирования удлиняется; для команд, не готовых инвестировать в неё, это ощущается как замедление.

Связка с ручным QA. Роль QA смещается от «прогона сценариев вручную» к проектированию приёмочных тестов и исследовательскому тестированию. Регрессия на уровне приёмки страхуется автоматически; ручное QA концентрируется на том, чего автоматизация не покрывает (исследовательские сессии, эвристики, UX). Это разгружает QA от рутины и поднимает ценность роли. Подробнее о месте автоматизации и ручного тестирования — в пирамиде тестирования.

Живая документация как побочный продукт. Набор зелёных приёмочных тестов читается как спецификация системы. Новому разработчику или приходящему аналитику проще понять «что система реально делает», читая тесты, а не устаревший Confluence. Это снижает порог входа и косвенно повышает bus-factor проекта.

Синергия с непрерывной интеграцией. Приёмочные тесты запускаются на каждой сборке в CI. Если они медленные (об этом — в рисках), их разбивают на уровни: быстрые приёмочные тесты на каждом коммите, полный приёмочный набор — на ночном билде. Это та же логика слоистости, что и в пирамиде тестирования.

Преимущества

Однозначные требования. Совместно написанные примеры устраняют трактовки. Спор о том, «что имел в виду заказчик», разрешается не возвратом к документу двухмесячной давности, а перечитыванием согласованной спецификации.

Ранний консенсус. Неоднозначности ловятся на фазе «Обсуди» — за столом, до кода. Это самое дешёвое место для исправления недопонимания; по мере движения к коду и далее стоимость правки растёт на порядки.

Исполняемая спецификация. Договорённости не просто записаны — они исполняются на каждой сборке. Если поведение системы расходится со спецификацией, это обнаруживается автоматически, а не в момент демо.

Снижение дефектов приёмки. Дефекты вида «не то, что просили» — самые дорогие, потому что их правка часто означает переделку целой фичи. ATDD систематически вылавливает их до кода. Качественный эффект (подтверждаемый отчётами Аджича по десяткам команд): дефектов приёмки меньше, а их средняя стоимость — ниже.

Живая документация. Зелёный набор приёмочных тестов — документация, которая не врёт. Это ценный актив для онбординга, аудита и передачи знаний между командами.

Мост между бизнесом и разработкой. Язык примеров понятен нетехническим стейкхолдерам (таблицы «вход → выход» читает любой заказчик). Это сокращает дистанцию между требованиями и реализацией и делает ревью приёмки осмысленным для бизнеса.

Недостатки и риски

Медленные e2e-приёмочные тесты. Если приёмочные тесты реализованы как полноценные end-to-end сценарии через UI, они медленные и хрупкие (flaky). Набор из сотен таких тестов превращает пайплайн в многочасовую очередь и подрывает доверие к спецификации. Решение — слоистость (быстрые приёмочные на уровне API/домена, e2e — точечно), но это требует инженерной зрелости. Подробнее — в пирамиде тестирования.

Накладные поддержания. Набор приёмочных тестов — это кодовая база, которую нужно поддерживать наравне с production-кодом: менять при эволюции требований, чинить хрупкие, обновлять fixture-ы. Команда без ресурса на это поддержку получает за год «зоопарк» тестов, из которого половина не запускается.

Вырождение в «тесты ради тестов». Если фаза «Обсуди» формальна (PO прислал примеры по почте, команда их формализовала без диалога), приёмочные тесты превращаются в ещё один слой рутины без раннего консенсуса. Симптом — тесты зелёные, а заказчик всё равно «не то имел в виду». Это означает, что ATDD выродился в автотесты без сути.

Зависимость от вовлечённости бизнеса. ATDD требует живого участия PO/заказчика на фазе планирования. Если бизнес «не имеет времени» и скидывает требования текстом, методология не работает: совместного написания нет, раннего консенсуса нет. Это предусловие, а не пожелание — и частый реальный барьер.

Риск тестирования реализации, а не поведения. Если приёмочные тесты привязаны к деталям реализации (конкретным UI-элементам, структуре БД), они ломаются при любом рефакторинге и перестают быть живой документацией. Граница между тестированием поведения и реализации тонка и требует навыка.

Не ускоряет первый коммит. Как и TDD, ATDD ощутимо удлиняет путь от «есть идея» до «первый зелёный пайплайн». Оплата — в долгую (меньше переделок), но руководитель, оценивающий по скорости первых спринтов, получит ложную картину «торможения».

Когда использовать

  • Продуктовая разработка с активным заказчиком. Есть PO/аналитик, готовый участвовать в написании примеров, и заказчик, доступный для диалога — главный сценарий применимости ATDD.
  • Сложные приёмочные сценарии. Много правил, ветвлений, граничных случаев — там, где абстрактные требования неизбежно трактуются по-разному; примеры дают однозначность.
  • Регуляторные требования к приёмке. Домены, где приёмка формальна и должна быть задокументирована (финансы, медицина, гос) — исполняемая спецификация даёт аудируемый след «что именно проверено».
  • Зрелая инженерная культура с CI. Приёмочные тесты должны запускаться автоматически на каждой сборке; без CI их ценность резко падает.
  • Команда, готовая инвестировать в планирование. Фаза «Обсуди + Дистиллируй» занимает время; команды, привыкшие «бросаться в код», должны быть готовы к смене ритма.
  • Долгоживущий продукт. Инвестиция в живую документацию окупается на горизонте месяцев и лет; для одноразовых прототипов — почти никогда.

Когда НЕ использовать

  • Exploratory-разработка и исследования. Когда заранее неизвестно, что именно должно получиться, фиксировать приёмку преждевременно — спецификация будет переписываться вслед за меняющимся пониманием. Здесь работают практики исследовательского тестирования и коротких экспериментов.
  • Нет вовлечённого заказчика/PO. Без соавтора со стороны бизнеса фаза «Обсуди» пуста; ATDD превращается в автотесты, написанные разработчиками в одиночку, без раннего консенсуса.
  • Чисто инфраструктурные задачи. CI/CD-пайплайны, миграции, инфраструктурный код — там, где нет «пользовательской функциональности» в смысле приёмки, ATDD плохо ложится; здесь работают TDD и инфраструктурное тестирование.
  • Команда без навыка автоматизации. Если команда не умеет писать поддерживаемые приёмочные тесты, первая попытка даёт хрупкий e2e-зоопарк и разочарование. Сначала — обучение и пилот; потом — масштабирование.
  • Жёсткие дедлайны с паникой. В режиме deadline-driven фаза совместного планирования отбрасывается первой; ATDD в таком окружении не приживается, пока не устранена первопричина.

Связанные подходы

ATDD — не единственный «*DD» в разработке; за разными аббревиатурами стоят разные «движущие силы». Статья входит в серию материалов о driven-подходах; ниже — краткая карта, со ссылками на уже опубликованные материалы базы знаний.

Разведение TDD / ATDD / BDD

TDD, ATDD и BDD часто путают, потому что все три «пишут тесты до кода». Разница — в уровне, драйвере и главном вопросе.

Ось сравнения TDD ATDD (этот материал) BDD
Уровень Юнит кода (функция, класс) Пользовательская функциональность (фича) Поведение фичи в сценариях
Драйвер Дизайн кода (тестируемость) Критерии приёмки Общий язык и понимание поведения
Главный вопрос «Хорошо ли написан код?» «Выполнены ли критерии приёмки?» «О чём мы договорились как о поведении?»
Формат теста Произвольный (xUnit, etc.) Произвольный (таблицы, сценарии, DSL) Given-When-Then (Gherkin)
Кто пишет Разработчик Вся команда + заказчик Вся команда + заказчик (Three Amigos)
Инструменты JUnit, pytest, Jest FitNesse, Robot Framework, SpecFlow Cucumber, JBehave, SpecFlow
Выход Чистый код + юнит-тесты Исполняемая спецификация приёмки Живая спецификация поведения на общем языке

Иначе говоря, на вопрос «что драйвит?» три подхода отвечают по-разному: TDD — дизайн кода, ATDD — приёмку фичи, BDD — понимание поведения через диалог. Они не конкурируют, а дополняют друг друга по уровням: BDD задаёт приёмочное поведение сверху, TDD страхует код снизу; ATDD исторически занимает промежуточное положение и во многом слился с BDD в современной трактовке. В зрелой кодовой базе все три сосуществуют, и именно их сочетание даёт когерентную культуру «поведение → требования → код → проверка».

Карта серии

  • TDD — Test Driven Development — родственный подход, где движущей силой выступают тесты как исполняемая спецификация. ATDD и TDD не конкурируют, а дополняют друг друга: ATDD задаёт рамку «что строим» на уровне фичи, TDD страхует реализацию на уровне юнитов.
  • BDD — Behaviour Driven Development — прямой потомок ATDD: BDD = ATDD + фокус на общий язык (Given-When-Then) и коммуникацию. ATDD шире по форме (любой исполняемый формат приёмочного теста), BDD строже по синтаксису и сильнее смещён в диалог бизнеса и разработки.
  • DDD — Domain Driven Design — родственный подход, где движущей силой выступает домен. DDD задаёт общий язык и модель предметной области; ATDD пользуется этим языком при формулировке примеров приёмки.
  • FDD — Feature Driven Development — организационная методология, где движущей силой выступает клиенто-ориентированная фича. FDD задаёт процесс доставки фичи, ATDD — её приёмку; на практике они сочетаемы.
  • MDD — Model Driven Development — модельно-ориентированный подход; концептуально дальше от ATDD, но разделяет идею «исполняемого артефакта как источника истины» (модель у MDD, спецификация-пример у ATDD).
  • XP — Extreme Programming — методология, в которой ATDD родился как практика приёмочного тестирования силами заказчика.
  • Agile и Scrum — процессные рамки, в которые ATDD встраивается через Definition of Ready / Definition of Done.
  • Acceptance testing — приёмочное тестирование как практика, которую ATDD поднимает на уровень спецификации.
  • Введение в тестирование и пирамида тестирования — место приёмочных тестов в общей системе контроля качества.
  • Политика нуля дефектов — работа с найденными дефектами приёмки в кодовой базе, где спецификация исполняема.

Родственные driven-подходы — TDD, BDD, DDD, FDD, MDD, а также «сатирические» варианты вроде Panic Driven Development — рассматриваются в соответствующих статьях серии.

Краткий вердикт для руководителя

ATDD — это инвестиция в раннюю договорённость, а не способ ускорить написание кода. Эффект: однозначные требования, исполняемая спецификация, меньше дефектов приёмки, живая документация, мост между бизнесом и разработкой. Цена: удлинённая фаза планирования, необходимость поддерживать набор приёмочных тестов, критическая зависимость от вовлечённости PO/заказчика. Берите, если у вас активный заказчик, сложные приёмочные сценарии и зрелый CI; фреймворк органично встраивается в DoR/DoD и культуру Agile. Не берите, если заказчика достучаться невозможно, продукт — чистая инфраструктура, или команда ещё не освоила автоматизацию. И помните: в современной трактовке ATDD во многом слился с BDD — если вам ближе строгий формат Given-When-Then и фокус на общем языке, выбирайте BDD; если формат примеров произволен и важна именно приёмка — ATDD.

Источники и материалы

Первоисточники и ключевые публикации

  • Lisa Crispin, Tip House. Testing Extreme Programming. Addison-Wesley, 2003 — первая систематизация приёмочного тестирования как полноправной части XP-процесса.
  • Gojko Adžić. Specification by Example: How Successful Teams Deliver the Right Software. Manning, 2011 — каноническое обобщение опыта десятков команд; паттерны совместного написания спецификаций через примеры.
  • Gojko Adžić. Bridging the Communication Gap. Neuri, 2009 — предтеча Specification by Example; коммуникация бизнеса и разработки через исполняемые примеры.
  • Ken Pugh. Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration. Addison-Wesley, 2010 — операционное описание ATDD в Lean-Agile контексте.
  • Dan North. Introducing BDD (Better Software, 2006) — статья, где North ввёл ATDD/BDD как ответ на проблемы коммуникации; помогает понять исторический переход.
  • Ward Cunningham. Fit (2002) — первый массовый инструмент ATDD; таблицы как исполняемые спецификации.

Связанные материалы базы знаний