automationstrategy

BDD vs TDD vs ATDD: когда что использовать в QA

TDD, BDD, ATDD — три аббревиатуры, которые часто путают и используют как синонимы. На самом деле — это три разных практики, у каждой своя цель и команда.

TDD — Test Driven Development

Кто пишет: разработчик.

Когда: до написания продакшен-кода.

Цикл: Red → Green → Refactor.

  1. Пишешь тест → он красный (Red).
  2. Пишешь минимальный код чтобы тест прошёл (Green).
  3. Рефакторишь не ломая тест.

Цель — дизайн кода через тесты. Побочный продукт — high coverage. QA-инженер редко участвует в TDD — это работа dev’а.

ATDD — Acceptance Test Driven Development

Кто пишет: трио — Product/Business Analyst + Developer + QA.

Когда: до начала разработки фичи.

Цикл:

  1. Команда обсуждает фичу.
  2. Совместно пишут acceptance тесты на бизнес-языке: «когда пользователь делает X, должно произойти Y».
  3. Разработчик реализует, QA проверяет что тесты проходят.

Цель — общее понимание требований. Acceptance тесты становятся живой документацией.

BDD — Behavior Driven Development

Кто пишет: продуктовые сотрудники + разработка + QA.

Когда: до и во время разработки.

Формат: Gherkin (Given / When / Then):

Feature: Login
  Scenario: Successful login
    Given user has account with email "user@example.com"
    When user enters email and password
    Then user is redirected to /dashboard

Технически BDD — это расширение ATDD с акцентом на естественный язык. Реализуется через Cucumber, SpecFlow, Behave.

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

TDD — если ты пишешь юнит-тесты и хочешь использовать их как инструмент дизайна. Преимущественно для разработчиков.

ATDD — если требования сложные и часто меняются. Полезно когда у тебя есть business analyst или PM который активно участвует.

BDD — если хочешь, чтобы acceptance criteria были читаемы продактом. Минус — overhead из-за Gherkin-слоя. Плюс — единый источник правды для всех ролей.

Подводные камни

TDD: догматизм

«Каждая строка кода должна быть закрыта тестом» — путь к 80% покрытию и куче бесполезных тестов на getter’ы. TDD — это инструмент, не религия. Пиши тесты на критичные части, не на тривиальное.

BDD: Gherkin без сценариев

Команды пишут Gherkin потому что «модно», но не привлекают product/QA на этапе обсуждения. В итоге Gherkin-файлы пишет разработчик в одиночку — теряется главная ценность (общее понимание). Лучше тогда уж pytest на Python.

ATDD: разрыв между тестом и реализацией

Acceptance-тест написали → разработчик не смотрит → реализует своё видение → тест проваливается → переписывают тест. Цикл «обсудили → реализовали → подтвердили» сломан.

Что делать QA

— Начни с ATDD — это самое полезное для QA. Просто привлекай разработчиков к обсуждению требований до начала кодинга. Минимум tooling.

— Не пытайся внедрить BDD на старый проект — нужен culture shift всей команды. Лучше для нового проекта.

— TDD оставь разработчикам — это их практика. QA может помочь обзорами тестов, но не писать их за них.

Подробнее: Martin Fowler — TDD, Dan North — Introducing BDD.