ATDD: Acceptance Test-Driven Development

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

Зачем нужно

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

Где используется

Agile-команды с практикой «Three Amigos» (dev + QA + PO)
Проекты с чёткими acceptance criteria в user stories
Системы с регуляторными требованиями, где нужна трассируемость
Интеграционное и E2E тестирование пользовательских сценариев

Основной контент

ATDD vs TDD vs BDD

Методология	Кто пишет тесты	Язык	Уровень
TDD	Разработчик	Технический (JS/TS)	Unit
BDD	Dev + QA	Given/When/Then	Feature
ATDD	Dev + QA + PO	Бизнес-язык	Acceptance/E2E

Цикл ATDD

1. Обсуждение (Three Amigos) → формулировка acceptance criteria
2. Написание acceptance test (Playwright/Cypress/Cucumber)
3. Тест RED — фичи нет, тест падает
4. Разработка по TDD внутри фичи
5. Тест GREEN — приёмочный тест проходит
6. Демонстрация заказчику

Пример: acceptance test на Playwright

// tests/checkout.spec.ts
import { test, expect } from '@playwright/test';

// Acceptance criterion: "Пользователь может оформить заказ,
// добавив товар в корзину и введя данные доставки"
test('оформление заказа — happy path', async ({ page }) => {
  // Given — пользователь на странице товара
  await page.goto('/products/42');

  // When — добавляет в корзину
  await page.click('[data-testid="add-to-cart"]');
  await page.click('[data-testid="go-to-checkout"]');

  // And — вводит данные доставки
  await page.fill('#name', 'Alice');
  await page.fill('#address', 'ул. Тестовая, 1');
  await page.click('[data-testid="place-order"]');

  // Then — видит подтверждение заказа
  await expect(page.locator('[data-testid="order-confirmation"]')).toBeVisible;
  await expect(page.locator('.order-number')).toHaveText(/ORD-\d+/);
});

Пример с Cucumber (Gherkin)

# features/checkout.feature
Feature: Оформление заказа

  Scenario: Успешное оформление заказа
    Given пользователь находится на странице товара "Книга по TDD"
    When он нажимает "Добавить в корзину"
    And переходит к оформлению заказа
    And вводит адрес доставки "ул. Тестовая, 1"
    And нажимает "Оформить заказ"
    Then он видит подтверждение с номером заказа

Связь с Definition of Done

Acceptance tests — формальный критерий завершённости user story. Story считается «Done» только когда все acceptance tests проходят в CI.

Частые ошибки

ATDD без реального участия PO — тесты пишет разработчик по своему пониманию требований; теряется главный смысл методологии
Слишком детальные acceptance tests — тест проверяет CSS-классы вместо пользовательского поведения; привязка к UI делает тесты хрупкими
Нет разделения с unit-тестами — acceptance test не должен тестировать детали реализации; он проверяет сценарий целиком
Acceptance tests в основном pipeline без изоляции — медленные E2E тесты блокируют CI; выноси их в отдельный stage