31.07.2026 03.08.2026

BDD — Behaviour Driven Development

Движущая сила: поведение системы, описанное на общем языке бизнеса (сценарии Given-When-Then).

Уровень применения: команда (требования) + код (автоматизация сценариев).

Статус: устоявшийся (Dan North, 2006; инструменты JBehave / Cucumber / SpecFlow).

Не путать с: TDD (инженерная микро-практика) и ATDD (критерии приёмки) — см. ниже развёрнутое разведение.

Общее

Behaviour Driven Development (BDD) — методология разработки, в которой первичной движущей силой выступает поведение системы, сформулированное на языке, одинаково понятном бизнесу и разработке. Поведение описывается в виде коротких сценариев по схеме «Дано — Когда — Тогда» (Given-When-Then); эти сценарии рождаются до написания кода, в совместном диалоге стейкхолдеров и команды, и затем исполняются как автоматические проверки. Ключевой тезис North: BDD — это не про тесты, а про понимание и согласование требований через общий язык; тесты здесь — побочный продукт, а не цель.

Подход был сформулирован Дэном Нортом (Dan North) в статье Introducing BDD (Better Software Magazine, 2006). Мотивация North была предельно конкретной: он начал применять TDD и обнаружил, что на вопрос «где начинать и что именно проверять» ответа в методе не было. Название «тестирование» сбивало с толку — нефтехнические стейкхолдеры не понимали, зачем «тесты» пишутся до кода, и отстранялись. North переименовал практику из «test-» в «behaviour-»: говорить о поведении оказалось естественно и бизнесу, и инженерам. Корни подхода — в совместной работе North с Крисом Маттсом (Chris Matts), который принёс в BDD идеи Domain-Driven Design (прежде всего — ubiquitous language) и практику feature injection — «внедрение фичи» через бизнес-цель.

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

BDD исторически вырос из попытки ответить на три вопроса, которые TDD оставил открытыми:

  1. Где начинать? TDD не объяснял, какую первую функцию проверять и откуда вообще берётся «спецификация» для юнит-теста.
  2. Сколько тестировать? TDD не давал критерия «достаточно»: когда останавливаться в написании проверок.
  3. Что именно проверять (и что не проверять)? TDD не помогал отличить важное поведение от второстепенного.

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

Словарь BDD минимален и держится на одном формате — Given-When-Then, предложенном North и позже популяризированном синтаксисом Gherkin (язык описания сценариев в Cucumber и аналогах). Один Feature (фича, бизнес-возможность) содержит один или несколько Scenario (сценариев); каждый сценарий строится по схеме «Дано некоторое начальное состояние — Когда происходит событие/действие — Тогда система должна ответить так-то». Этот формат — не «технический артефакт», а компактный язык описания примеров поведения, читаемый и нетехническим участником.

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

BDD — это не «писать Gherkin», а набор принципов, которые в совокупности меняют то, как требования превращаются в код. Ниже — формулировка каждого с пояснением, какую конкретную проблему он решает.

Поведение прежде тестов (behaviour over tests). В центре внимания — не «как проверить код», а «как система должна себя вести». Проблема: слово «тест» в TDD провоцировало разработчиков писать проверки реализации, а бизнес — отстраняться («это техническое»). Переключение на «поведение» возвращает фокус на observable-эффекты системы, видимые пользователем, и делает спецификацию интересной нетехническим участникам.

Общий язык (ubiquitous language) с бизнесом. Сценарии пишутся словами, которыми бизнес описывает свою предметную область. Проблема: классические требования (ТЗ на десятки страниц) и тесты (код на программистском жаргоне) живут в двух непересекающихся мирах; каждое «перевод» между ними — точка потери смысла. BDD требует, чтобы терминология сценария совпадала с разговорным языком эксперта — это тот же принцип единого языка, что и в DDD, но применённый к требованиям и примерам.

Примеры вместо абстрактных требований (specification by example). Требование формулируется не как общее правило («корректно применяет скидку»), а как конкретный пример («дано заказ на 100 ₽ и скидка 10 %, тогда итог 90 ₽»). Проблема: абстрактные требования допускают десятки трактовок; стороны расходятся в понимании, не подозревая об этом, и дефект обнаруживается только в приёмке. Конкретный пример с числами и шагами либо понятен всем однозначно, либо вскрывает неоднозначность прямо на сессии — до того, как написана строка кода.

Сценарии Given-When-Then. Структура «Дано — Когда — Тогда» фиксирует три обязательных элемента: предусловие (начальное состояние), действие (триггер) и ожидаемый результат. Проблема: без явной структуры требования смешивают «что было», «что сделали» и «что получили», и пробел в любом из трёх остаётся незамеченным. Шаблон вынуждает автора дописать недостающее.

Outside-in: от приёмочного сценария к юнитам. Разработка идёт «снаружи внутрь»: сначала пишется приёмочный BDD-сценарий (что увидит пользователь), затем — код, его удовлетворяющий, причём внутренние компоненты проектируются «по требованию» сценария, через вложенные циклы TDD на юнит-уровне. Проблема: классический bottom-up («построим компоненты, потом соединим») часто даёт систему, которая работает правильно внутри, но не решает реальной бизнес-задачи снаружи. Outside-in гарантирует, что каждый внутренний модуль существует лишь постольку, поскольку он нужен видимому поведению.

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

Живая документация (living documentation). Сценарии, прошедшие автоматизацию, превращаются в исполняемую спецификацию, которая всегда актуальна: если поведение изменилось — сценарий краснеет, если зелёный — он соответствует коду. Проблема: статичные документ и ТЗ устаревают в момент публикации и через полгода безнадёжно расходятся с реальностью. Living documentation не может устареть по построению (она либо зелёная и верная, либо красная и тревожная).

Принципы — система, а не меню. Gherkin-сценарии без three amigos превращаются в «переписанные тесты» без ценности; общий язык без outside-in не страхует от ненужного кода; outside-in без живой документации не даёт обратной связи. Частичное внедрение создаёт «BDD-theatre» — формальное наличие .feature-файлов без заявленного эффекта; полное — даёт синергию требований, кода и документации.

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

BDD оперирует минимальным, но строго структурированным набором артефактов. Покажем механику на формате Gherkin (де-факто стандарт описания сценариев в Cucumber, JBehave, SpecFlow, Behat).

Формат сценария

Каждая фича (Feature) — это бизнес-возможность, описанная кратким заголовком и одним-двумя предложениями ценности. Внутри фичи — один или несколько сценариев (Scenario), каждый из которых иллюстрирует один пример поведения по схеме Given-When-Then:

# language: ru
Функционал: Применение скидки к заказу
  Как маркетолог
  Я хочу применять процентную скидку к заказу
  Чтобы поощрять повторные покупки

  Сценарий: Корректное применение скидки к непустому заказу
    Допустим заказ на сумму 100 рублей
    И применена скидка 10 процентов
    Когда заказ оформляется
    Тогда итоговая сумма заказа равна 90 рублей

  Сценарий: Скидка не делает цену отрицательной
    Допустим заказ на сумму 50 рублей
    И применена скидка 200 процентов
    Когда заказ оформляется
    Тогда итоговая сумма заказа равна 0 рублей

Части сценария соответствуют трём обязательным элементам:

Часть Ключевые слова Смысл
Контекст Допустим / Дано (Given), И / Но (And / But) Предусловие — начальное состояние мира до действия
Действие Когда (When) Триггер — событие или действие пользователя, которое запускает поведение
Результат Тогда (Then), И Постусловие — наблюдаемый результат: изменённое состояние, выданные данные, отправленное сообщение

Ключевые слова локализуемы (# language: ru переключает их на русский), но скелет Given-When-Then неизменен. Важно: в строгом BDD Then описывает наблюдаемый результат, а не вызовы внутренних методов — иначе сценарий проверяет реализацию, а не поведение.

Связка Feature → Scenario → Step definitions

Gherkin-файл — это исполняемая спецификация лишь потенциально: сами по себе строки «Допустим заказ на сумму 100 рублей» ничего не проверяют. Их оживляет связующий код — так называемые step definitions (определения шагов). Каждый шаг сценария связывается регулярным выражением или шаблоном с функцией в коде:

from pytest_bdd import scenarios, given, when, then

scenarios("discount.feature")


@given("заказ на сумму 100 рублей")
def order_100():
    return Order(amount=Money(100, "RUB"))


@given("применена скидка 10 процентов")
def apply_discount_10(order_100):
    order_100.apply_discount(Percent(10))


@when("заказ оформляется")
def place(order_100):
    order_100.place()


@then("итоговая сумма заказа равна 90 рублей")
def assert_total(order_100):
    assert order_100.total() == Money(90, "RUB")

Когда раннер запускает фичу, он читает сценарий, для каждой строки находит соответствующий step definition, выполняет соответствующую функцию и сообщает результат: зелёный, если все Then прошли, красный — если хотя бы один шаг упал. Совокупность .feature-файлов и step definitions — это и есть исполняемая спецификация (executable specification).

Инструментарий

BDD-инструменты различаются языком и экосистемой, но концептуально устроены одинаково: парсер Gherkin + связывание шагов с кодом + отчёт о прохождении.

Инструмент Экосистема Особенности
Cucumber JVM, Ruby, JS, и др. Самый распространённый; породил формат Gherkin как стандарт
JBehave JVM Первая реализация, написана самим North; меньше распространена ныне
SpecFlow .NET Естественный выбор для C#/.NET-проектов
Behat PHP Стандарт в Symfony-сообществе
pytest-bdd Python Интеграция Gherkin с pytest

Выбор инструмента вторичен: дисциплина и культура важнее конкретного раннера. Команда, освоившая Cucumber, без труда перейдёт на SpecFlow; команда, не понявшая сути BDD, не спасёт ни один инструмент.

Цикл работы

В отличие от TDD с его минутным Red-Green-Refactor, цикл BDD длиннее и охватывает уровни от требований до кода:

  1. Соберись (Discovery). Three amigos (аналитик, разработчик, QA) обсуждают предстоящую фичу, проговаривая её на конкретных примерах. Цель — обнаружить неоднозначности и пробелы до написания чего-либо. Часто используется техника Example Mapping (Matt Wynne): фича → правила → конкретные примеры → вопросы без ответа.
  2. Опиши поведение (Formulation). Договорённости оформляются в Gherkin-сценарии. На этом этапе сценарии ещё не автоматизированы, но уже читаемы всеми участниками.
  3. Автоматизируй сценарий (Automation). Пишутся step definitions; сценарий запускается и обязательно падает — потому что кода под ним ещё нет. Это аналог фазы Red в TDD, но на уровне приёмки.
  4. Спустись к юнитам (Implementation). Чтобы заставить сценарий позеленеть, разработчик пишет код — и делает это через классические циклы TDD внутри: каждый компонент рождается из красного юнит-теста. Так BDD и TDD складываются в единый процесс: BDD задаёт «какое поведение», TDD — «как устроено внутри».
  5. Повтори. По мере прохождения сценариев список фич пополняется; живая документация растёт и остаётся зелёной.

Важное свойство цикла: обсуждение (Discovery) ценнее автоматизации. North и Adzic неоднократно подчёркивают — если на сессии three amigos команда выявила неясность требования и поправила его, BDD уже окупил себя, даже если сценарий потом не автоматизировался. Автоматизация — усиление, а не цель.

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

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

«Три амиго» как ритуал, а не разовая встреча. Самая ценная практика BDD — не Gherkin, а регулярная совместная сессия, на которой аналитик, разработчик и QA разбирают предстоящую фичу через конкретные примеры. Проблема, которую она решает: в традиционном процессе аналитик пишет ТЗ, разработчик реализует «как понял», QA проверяет «что получилось» — и каждый работает со своей версией требований. Three amigos заменяет три «одиночные версии» одной совместно согласованной. В зрелой команде эта сессия встраивается в рефайнмент бэклога и не требует отдельного формального ритуала.

Shift-left на уровень требований. Если TDD смещает обнаружение дефектов с этапа тестирования на этап кодирования, то BDD смещает его ещё левее — на этап требований. Неоднозначность, противоречие или пропуск в требовании обнаруживаются в разговоре, до любой строки кода. Это самый дешёвый класс дефекта — тот, что не написан. Подробнее о shifted-логике стоимости дефектов — в материалах о жизненном цикле разработки.

Живые спецификации (living documentation) вместо мёртвого ТЗ. Зелёный набор BDD-сценариев — это документация, которая по определению не может устареть: если поведение изменилось, сценарий краснеет и привлекает внимание; если зелёный — он соответствует коду. Это радикально снижает риск «дока vs код», который преследует классические ТЗ и регламенты. Новому участнику проще понять «что вообще делает эта фича», читая .feature-файлы, а не расшифровывая код.

Влияние на бэклог и рефайнмент. Фича считается готовой к разработке не тогда, когда «есть описание», а когда у неё есть согласованные сценарии. Это поднимает планку grooming: задача без примеров поведения просто не берётся в спринт. Для Scrum-команд это естественное усиление критериев готовности (Definition of Ready).

Связь с определением готовности (Definition of Done). BDD-сценарии органично входят в Agile-определение «готово»: фича готова, когда все её приёмочные сценарии зелёные и проходят в CI. Это превращает расплывчатое «работает как надо» в проверяемое «все Given-When-Then проходят автоматически» и снимает вечный спор между разработкой и QA на демо.

Мост между стейкхолдерами и кодом. Сценарии читаемы нетехническими участниками — продакт-менеджером, заказчиком, юристом, аудитором. Это впервые делает требования и их проверку общим достоянием, а не закрытой инженерной территорией. В регулируемых доменах это дополнительный плюс: BDD-сценарии служат аудируемым следом того, какое поведение требовалось и как именно оно проверено.

Синергия с TDD и DDD. BDD не заменяет, а надстраивается над ними. BDD-сценарий задаёт приёмочное поведение; внутри его реализации разработчик ведёт цикл Red-Green-Refactor TDD; а термины, которыми написаны сценарии и шаги, берутся из единого языка DDD. Три подхода складываются в когерентную инженерную культуру: DDD даёт язык, BDD — примеры поведения на этом языке, TDD — код, страхующий поведение по уровням.

Синергия с AI-генерацией кода. Gherkin-сценарии — это исполняемые спецификации на естественном языке, которые AI-агенты читают напрямую. В AIDD BDD-сценарии становятся особенно ценным мостом между бизнес-требованием и автоматически сгенерированным кодом: AI получает однозначное описание поведения, а тест-раннер выступает gate-ом, проверяющим соответствие сгенерированного кода спецификации.

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

Общий язык. Требование, спецификация и автоматическая проверка говорят на одном языке — языке бизнеса. Это устраняет «телефонный испорченный» перевод между стейкхолдером и кодом, где каждый пересказ теряет смысл.

Раннее выявление неоднозначности требований. Попытка записать требование в виде конкретного примера «Дано X — Когда Y — Тогда Z» немедленно обнажает пробелы: неизвестно начальное состояние, неоднозначен результат, пропущен триггер. Эти дефекты требований обнаруживаются на сессии three amigos, а не через две недели в приёмке.

Исполняемая документация. Зелёный набор сценариев — это документация, которая не может устареть. Она служит одновременно спецификацией, регрессионным тестом и средством онбординга.

Мост между стейкхолдерами и кодом. Нетехнические участники наконец-то могут читать и обсуждать «тесты» — потому что это сценарии на их языке. Это снижает пропасть между бизнесом и инженерией и возвращает заказчику контроль над тем, что именно строится.

Регрессионная страховка на уровне поведения. Однажды записанный и автоматизированный сценарий страхует видимое поведение от незаметной поломки при рефакторинге. Это дополняет TDD-юниты уровнем приёмочных проверок — место BDD в пирамиде тестирования среди более медленных, но зато ориентированных на пользователя тестов.

Снижение переработок. Дефекты требований — самые дорогие (их исправление затрагивает архитектуру и весь реализованный код). Перенос их обнаружения на этап требований экономит недели переработок в долгую; качественный вывод стабилен во множестве отчётов (Adzic, Specification by Example, 2011).

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

Сценарии как «переписанные тесты». Самый частый провал: команда осваивает синтаксис Gherkin, но не осваивает суть — и начинает переписывать старые юнит- и интеграционные тесты в формате Given-When-Then. Результат: внешне «BDD», внутри — те же технические проверки, только менее читаемые и более хрупкие. Симптом: в Then проверяются вызовы внутренних методов, а в Given — состояние базы данных. Это вырождение BDD в косметику.

Накладные на поддержание step definitions. Каждое изменение поведения требует синхронной правки и .feature-файла, и step definitions, и production-кода. Если шаги спроектированы плохо (жёстко привязаны к деталям реализации), малейший рефакторинг ломает десятки сценариев. Со временем step-слой раздувается и сам становится объектом поддержки, что съедает часть выгод.

Хрупкие e2e-сценарии. BDD-сценарии часто исполняются как end-to-end-проверки через UI или API, а такие проверки медленны и хрупки: падают из-за таймингов, внешних сервисов, изменения верстки. Команда, которая автоматизировала все сценарии как e2e, получает длинный, ненадёжный набор, подрывающий доверие к «зелёному». Подробнее о соотношении слоёв — в пирамиде тестирования: BDD-сценарии — это верхний, тонкий слой, а не основа пирамиды.

Синдром «Cucumber как тестовый фреймворк для юнитов». Распространённая ошибка — пытаться описывать на Gherkin юнит-проверки уровня discount(100, 10) == 90. Это засоряет .feature-файлы техническими деталями, убивает читаемость для бизнеса и игнорирует разделение уровней: юнит-поведение — удел TDD, BDD — уровень фич и сценариев.

Иллюзия «просто писать Gherkin». Команда, начавшая с синтаксиса и пропустившая Discovery, получает аккуратные .feature-файлы, которые не отражают реальных требований (потому что их писал один разработчик, а не three amigos). Сценарии зелёные, а продукт — не тот. Это симптом пропуска главного принципа — совместного обсуждения.

Ложная уверенность. Зелёный набор сценариев не означает полноту спецификации: он означает лишь, что проверено то поведение, о котором догадались написать. Непредусмотренные случаи (о них не подумали) остаются незастрахованными. «Все сценарии проходят» ≠ «система правильная».

Стоимость входа и обучения. BDD требует развитого навыка: умения писать читаемые сценарии, вести three amigos, проектировать step-слой так, чтобы он не хрупчил. Команда без этого навыка получает формальные .feature-файлы и разочарование. Внедрение «с понедельника» в неподготовленной команде почти всегда даёт «BDD-theatre».

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

  • Сложное бизнес-поведение. Домены с запутанными правилами, множеством ветвлений, неочевидными приоритетами — главный случай для BDD. Конкретные примеры поведения здесь дают максимальную отдачу.
  • Нужен мост бизнес ↔ разработка. Когда стейкхолдеры и инженеры говорят на разных языках и постоянно расходятся в понимании, BDD-сценарии дают общий носитель смысла.
  • Долгоживущие продукты. Инвестиция в живую документацию окупается, если продукт развивается годами; для одноразовых скриптов — почти никогда.
  • Регулируемые домены. Финтех, страхование, медицина — там, где важен аудируемый след «какое поведение требовалось и как проверено», BDD-сценарии служат прямым аргументом для аудиторов.
  • Команда с устоявшейся культурой Agile / Scrum. BDD естественно ложится на короткие итерации и рефайнмент бэклога, дополняя процесс инженерной и аналитической дисциплиной.
  • Вовлечённый бизнес. Если заказчик или продуктовый владелец готов выделять время на сессии three amigos — BDD работает. Это предусловие, а не пожелание.

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

  • Чисто технические и инфраструктурные задачи. Оптимизация SQL-запроса, настройка CI/CD, миграция схемы — поведение здесь техническое, стейкхолдеров-нетехнарей нет, и общий язык с бизнесом не нужен. Здесь работает TDD, а BDD избыточен.
  • Визуал и эстетика UI. Раскладка, анимации, визуальное восприятие плохо описываются шагами Given-When-Then. Здесь работают визуальное регрессионное тестирование и ручное QA.
  • Прототипы и исследования. Когда цель — быстро проверить гипотезу и, возможно, выбросить код, инвестиции в сценарии и step definitions преждевременны. Сначала — гипотеза, потом (если выживет) — BDD.
  • Нет вовлечённого бизнеса. Если стейкхолдеры недоступны или не желают участвовать в обсуждении, BDD вырождается в монолог разработчика, пишущего Gherkin в одиночку. В этом случае ценность надстройки над TDD теряется — достаточно обычных тестов.
  • Команда без навыка и без времени на обучение. Внедрение BDD «с понедельника» в команде без опыта совместной работы с требованиями даёт формальные .feature-файлы без эффекта. Сначала — пилот на одной фиче и обучение; потом — масштабирование.
  • Жёсткие «горящие» дедлайны. Когда процессом управляет паника, ритуалы three amigos отбрасываются как «лишние встречи». Это симптом больного процесса; в таком режиме BDD не приживётся, пока не устранена первопричина.

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

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

Подход Движущая сила Что управляет дизайном Уровень применения
BDD Поведение Сценарии Given-When-Then на уровне требований Команда и заказчик
TDD Тесты Тесты как исполняемая спецификация (Red-Green-Refactor) Код и команда
DDD Домен Модель предметной области и единый язык Команда и организация
ATDD Критерии приёмки Тесты приёмки как драйвер Вся команда с заказчиком
FDD (в работе серии) Фичи Дизайн по списку функций Команда

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

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

  • TDD — инженерная микро-практика. Цикл Red-Green-Refactor на юнит-уровне; драйвер — один разработчик; главный вопрос — «как проектировать код так, чтобы он был тестируемым и слабосвязанным». Тесты здесь управляют дизайном кода.
  • ATDD (Acceptance Test Driven Development) — тесты приёмки пишутся до реализации фичи; драйвер — вся команда с заказчиком; главный вопрос — «выполнены ли критерии приёмки». Тесты здесь управляют приёмкой фичи.
  • BDD (этот материал) — расширение с акцентом на общий язык и сценарии поведения; драйвер — совместный диалог three amigos; главный вопрос — «как именно система должна себя вести и понимаем ли мы это одинаково». Сценарии здесь управляют пониманием поведения через коммуникацию.

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

  • TDD — Test Driven Development — родственный подход, где движущей силой выступают тесты как исполняемая спецификация. BDD и TDD дополняют друг друга: BDD задаёт поведение на уровне фичи, TDD страхует реализацию на уровне юнитов.
  • DDD — Domain Driven Design — единый язык (ubiquitous language), которым написаны BDD-сценарии, берётся из модели предметной области; DDD и BDD разделяют один и тот же принцип общего языка, применённый к разным артефактам (модель vs требования).
  • FDD — Feature Driven Development — организационная методология, где движущей силой выступает клиенто-ориентированная фича. Концептуально BDD ближе к требованиям и коммуникации, FDD — к процессу и масштабированию; обе методологии работают с «фичами», но понимают их по-разному (сценарий поведения vs единица доставки).
  • MDD — Model Driven Development — родственный подход, где движущей силой выступает формальная модель. BDD и MDD сдвигают фокус вверх по жизненному циклу, но на разные артефакты: BDD — на требования, MDD — на архитектуру.
  • AIDD — AI-Driven Development: Gherkin-сценарии как исполняемые спецификации на естественном языке, которые AI читает напрямую, а раннер исполняет как gate.
  • Agile и Scrum — процессные рамки, в которые BDD встраивается через рефайнмент бэклога и Definition of Done.
  • SDLC — где BDD живёт внутри жизненного цикла: прежде всего на стыке фаз требований и тестирования, выполняя shift-left обнаружения дефектов.
  • Введение в тестирование и пирамида тестирования — место BDD-сценариев в общей системе контроля качества (верхний, тонкий слой).
  • Политика нуля дефектов — как работать с найденными проблемами в кодовой базе, где есть живая спецификация.

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

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

BDD — это инвестиция в общее понимание между бизнесом и разработкой, а не способ писать тесты модно. Эффект: раннее выявление неоднозначности требований, общий язык, исполняемая документация, мост между стейкхолдерами и кодом. Цена: время на ритуалы three amigos, поддержание step definitions, обучение команды писать читаемые сценарии. Берите, если поведение сложное, бизнес вовлечён, продукт долгоживущий, а команда готова к совместной работе с требованиями. Не берите, если задачи чисто технические, бизнеса в команде нет, горизонт короткий, или процессом управляет паника дедлайнов. Оценивать эффект BDD на горизонте одного спринта — главная ошибка внедрения; эффект проявляется на горизонте месяцев и лет, когда живая спецификация накапливается и требования перестают «расходиться» с кодом по умолчанию.

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

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

  • Dan North. Introducing BDD (Better Software Magazine, 2006) — фундаментальный первоисточник, формулировка перехода от «test-» к «behaviour-» и мотивации методологии.
  • Dan North. What’s in a Story? (dannorth.net, 2006) — канонический шаблон BDD-истории (story) и её структуры.
  • Gojko Adzic. Bridging the Communication Gap. Neuri, 2009 — систематизация роли примеров и совместной работы в требованиях.
  • Gojko Adzic. Specification by Example. Manning, 2011 — отраслевое исследование десятков команд, применяющих BDD/Specification by Example; кейс-стади и шаблоны.
  • Matt Wynne, Aslak Hellesøy. The Cucumber Book: Behaviour-Driven Development for Testers and Developers. Pragmatic Bookshelf — практическое руководство по Cucumber и Gherkin.
  • Martin Fowler. GivenWhenThen, BDD (martinfowler.com) — аналитические статьи, разъясняющие ключевые понятия и контекст применения.
  • Liz Keogh. BDD (lizkeogh.com, серия статей и докладов) — рефлексия одного из ранних адептов и популяризаторов подхода.

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

  • TDD — Test Driven Development — родственный driven-подход; BDD надстраивается над TDD, задавая поведение на уровне фичи.
  • DDD — Domain Driven Design — общий источник принципа ubiquitous language; терминология сценариев берётся из модели предметной области.
  • AIDD — BDD-сценарии как исполняемые спецификации для AI-генерации кода.
  • Введение в тестирование и пирамида тестирования — место BDD-сценариев в общей системе качества.
  • SDLC — BDD как инструмент shift-left на уровне требований.