Метод BDM

Метод BDM (от англ. _Behavior-Driven Development_, разработка, управляемая поведением) — это методология разработки программного обеспечения, которая расширяет принципы TDD (Test-Driven Development, разработка через тестирование) и DDD (Domain-Driven Design, предметно-ориентированное проектирование). Основная идея BDM заключается в описании поведения системы на естественном, близком к человеческому языке, понятном как разработчикам, так и заказчикам, тестировщикам и менеджерам. В отличие от TDD, где тесты пишутся на уровне кода (обычно юнит-тесты), BDM фокусируется на функциональном поведении системы с точки зрения пользователя, используя для этого формализованные сценарии.

История возникновения

Метод BDM был предложен Дэном Нортом (Dan North) в 2003 году как ответ на проблемы, возникающие при внедрении TDD в крупных проектах. Ключевой проблемой TDD было то, что тесты, написанные разработчиками, часто были слишком техническими и непонятными для бизнес-аналитиков и заказчиков. Это приводило к разрыву между требованиями к системе и её реализацией.

Норт сформулировал основные принципы BDM:

• Достаточность — пишется ровно столько тестов, сколько необходимо для реализации текущего поведения.
• Читаемость — сценарии должны быть написаны на языке, понятном всем участникам проекта.
• Автоматизация — сценарии должны быть автоматически исполняемыми.

В 2006 году была выпущена первая версия фреймворка JBehave для Java, а затем появились аналоги для других языков: RSpec (Ruby), Behat (PHP), SpecFlow (.NET) и Cucumber (многоплатформенный). Cucumber, созданный Аскеллом Хеллесой (Aslak Hellesøy) в 2008 году, стал наиболее популярным инструментом BDM, популяризовав формат Gherkin — язык описания сценариев.

Основные концепции

Язык Gherkin

Gherkin — это структурированный язык, использующий ключевые слова для описания сценариев поведения. Основные конструкции:

• Feature (Функция) — заголовок функциональности.
• Scenario (Сценарий) — конкретный пример поведения.
• Given (Дано) — предварительное условие (контекст).
• When (Когда) — действие пользователя или системы.
• Then (Тогда) — ожидаемый результат.
• And (И) / But (Но) — дополнительные условия или результаты.

Пример сценария на Gherkin: ``` Функция: Вход в систему Как зарегистрированный пользователь Я хочу войти в систему Чтобы получить доступ к личному кабинету

Сценарий: Успешный вход с правильными данными Дано пользователь находится на странице входа И вводит логин "user1" И вводит пароль "pass123" Когда нажимает кнопку "Войти" Тогда система перенаправляет на страницу личного кабинета И отображается приветствие "Здравствуйте, user1" ```

Трёхстороннее взаимодействие (Three Amigos)

BDM предполагает, что сценарии пишутся совместно тремя сторонами:

• Разработчик — отвечает за техническую реализацию.
• Тестировщик — проверяет корректность и полноту сценариев.
• Бизнес-аналитик или заказчик — формулирует требования на предметном языке.

Этот подход, известный как «Три амиго» (Three Amigos), позволяет выявить неоднозначности и противоречия в требованиях на ранних этапах.

Жизненный цикл BDM-сценария

1. Написание сценария на языке Gherkin (обычно в файлах с расширением .feature).
2. Автоматизация шагов — разработчик пишет код, который связывает ключевые слова Gherkin с реальными действиями системы (например, кликами по кнопкам, проверками содержимого страницы).
3. Выполнение сценария — сценарий запускается как автоматический тест. Если шаг не реализован, тест падает с сообщением о неопределённом шаге.
4. Рефакторинг — после успешного прохождения сценария код может быть улучшен без изменения поведения.

Отличие от TDD и ATDD

BDM часто рассматривается как эволюция ATDD, где акцент смещается с формальных тестов на описание поведения.

Инструменты и фреймворки

Наиболее распространённые инструменты, поддерживающие BDM:

• Cucumber (Java, Ruby, JavaScript, .NET) — самый популярный фреймворк, использующий Gherkin.
• SpecFlow (.NET) — аналог Cucumber для платформы .NET.
• Behave (Python) — фреймворк для Python.
• Behat (PHP) — фреймворк для PHP.
• JBehave (Java) — один из первых фреймворков BDM.
• RSpec (Ruby) — изначально инструмент для TDD, но активно используется в BDM-подходе.

Преимущества и недостатки

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

• Единый язык — все участники проекта (включая заказчиков) понимают сценарии, что снижает риск недопонимания.
• Автоматизация тестирования — сценарии становятся исполняемыми тестами, которые можно запускать регулярно.
• Документация в реальном времени — файлы .feature служат живой документацией, которая всегда соответствует текущему поведению системы.
• Раннее выявление ошибок — неоднозначности в требованиях обнаруживаются до начала разработки.

Недостатки

• Сложность поддержки — при изменении требований необходимо обновлять и сценарии, и код шагов, что может быть затратным.
• Зависимость от качества сценариев — плохо написанные сценарии (слишком детальные или слишком абстрактные) снижают ценность подхода.
• Необходимость обучения — команда должна освоить Gherkin и принципы BDM, что требует времени.
• Ограниченная применимость — BDM наиболее эффективен для систем с чётко определённым пользовательским интерфейсом или API; для низкоуровневых библиотек или алгоритмов он менее полезен.

Применение в России

В российской IT-индустрии метод BDM используется в основном в крупных компаниях, занимающихся разработкой сложных корпоративных систем, банковского ПО и веб-сервисов. Например, в СберТехе, Яндекс.Такси и ряде финтех-стартапов BDM применяется для автоматизации приёмочного тестирования. Однако его распространение ограничено из-за традиционного уклонения многих российских команд в сторону TDD или ручного тестирования, а также из-за необходимости перевода всех сценариев на русский язык для бизнес-аналитиков, что может создавать дополнительные сложности при интеграции с международными инструментами.

Критика

Основные критические замечания в адрес BDM:

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

Источники

• Норт, Д. (2003). Introducing BDD. Better Software Magazine.
• Хеллесой, А. (2008). The Cucumber Book: Behaviour-Driven Development for Testers and Developers. Pragmatic Bookshelf.
• Фаулер, М. (2013). BDD and TDD. MartinFowler.com.
• Смарт, Дж. (2014). BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle. Manning Publications.