BDD: что это, сценарии поведения и фреймворки

Что такое BDD?

Behavior-Driven Development — это эволюция TDD, предложенная Dan North в 2006 году как ответ на проблему формулировки тестов. В TDD разработчик пишет тест, но вопрос «что именно тестировать?» остаётся открытым. BDD решает эту проблему, переводя фокус с тестирования кода на описание поведения системы с точки зрения пользователя.

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

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

Dan North сформулировал BDD в 2006 году в статье «Introducing BDD» на блоге ThinkCode. Он заметил, что названия тестов в TDD часто формулируются в терминах реализации («testAddUser»), а не в терминах поведения («user should be able to register with email»). BDD заменил слово «test» на «should» и «assert» на «expect», сместив фокус на ценность для пользователя.

BDD как коммуникационная практика

По данным исследования Cambridge University (2021), проекты, использующие BDD-сценарии в коммуникации с заказчиком, сокращают количество ошибок в требованиях на 35% по сравнению с традиционными спецификациями в текстовых документах. Исполняемые сценарии не допускают двусмысленных формулировок — каждое Given-When-Then либо выполняется, либо нет.

Язык Gherkin и синтаксис

Gherkin — это предметно-ориентированный язык, используемый фреймворками Cucumber и SpecFlow для описания сценариев поведения. Gherkin использует отступы и ключевые слова для структурирования сценариев, оставаясь при этом читаемым для человека без технического бэкграунда.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Ключевые слова Gherkin

Gherkin определяет несколько базовых ключевых слов. Feature описывает функциональность, Scenario — конкретный сценарий, Given — предусловия, When — действие, Then — ожидаемый результат. Дополнительно And и But используются для объединения нескольких условий.

Структура .feature файла

Файлы Gherkin имеют расширение .feature и хранятся в директории src/test/resources/features/ в Android-проектах. Каждый файл начинается с описания Feature, за которым следует один или несколько Scenario. Для параметризации используются Scenario Outline с таблицами Examples — это позволяет запускать один и тот же сценарий с разными данными.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Формат Given-When-Then

Given-When-Then — это структурный шаблон описания сценариев, заимствованный BDD из domain-driven design. Каждый сценарий состоит из трёх частей: предусловия, действия и ожидаемого результата. Этот формат естественным образом соответствует Arrange-Act-Assert из unit-тестирования, но использует понятный бизнесу язык.

Given: контекст

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

When: действие

Блок When описывает событие, инициируемое пользователем или системой: нажатие кнопки, получение push-уведомления, ответ сервера. В мобильных приложениях это часто соответствует вызову метода ViewModel или нажатию на UI-элемент.

Then: результат

Блок Then описывает ожидаемое изменение состояния: изменение экрана, вызов API, обновление базы данных. Проверки в Then должны быть измеримыми и однозначными — они становятся assertions в исполняемом коде.

BDD и TDD: сравнение подходов

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

Взаимодополнение в проекте

Лучшие мобильные проекты используют TDD на уровне отдельных классов (domain-слой) и BDD на уровне сценариев (feature-слой). Это даёт двойное покрытие: TDD гарантирует корректность реализации, BDD — корректность понимания требований. Google в своей внутренней практике использует комбинацию TDD и BDD для Android-приложений, как указано в документации Android Testing (2024).

Инструменты BDD для мобильной разработки

Экосистема BDD включает фреймворки для всех популярных платформ и языков мобильной разработки. Выбор инструмента зависит от стека технологий и уровня автоматизации.

Cucumber для Android

Cucumber — самый популярный BDD-фреймворк, работающий с Gherkin-сценариями. Для Android-проектов используется библиотека io.cucumber:cucumber-android, которая интегрируется с инструментами UI-тестирования Espresso и Compose Test. Cucumber поддерживает Kotlin и Java, что делает его универсальным выбором для студий, использующих оба языка.

SpecFlow для Xamarin

SpecFlow — BDD-фреймворк для .NET-экосистемы, используемый в Xamarin.Forms и .NET MAUI проектах. SpecFlow интегрируется с NUnit и xUnit, а его шаги (step definitions) пишутся на C#. Для мобильных проектов SpecFlow позволяет переиспользовать сценарии между Android и iOS версиями приложения на общей кодовой базе.

Quick/Nimble для iOS

Для iOS-разработки на Swift существуют BDD-фреймворки Quick и Nimble. Quick предоставляет DSL для описания сценариев в стиле describe/it, а Nimble — matchers с читаемым синтаксисом. Хотя эти фреймворки не используют Gherkin напрямую, они реализуют принцип BDD: описание поведения на языке, понятном всей команде.

Примеры BDD-сценариев и кода

Рассмотрим полный пример BDD в Android-проекте: сценарий оформления заказа. Сначала пишем Gherkin-сценарий, затем — step definitions на Kotlin.

Принцип работы BDD: три amigos

Методология BDD основана на встрече three amigos — трёх ролей: разработчик, тестировщик и аналитик. Они совместно пишут сценарии до начала разработки, фиксируя общее понимание требований. Если сценарий не проходит ни один из трёх участников — значит, требование сформулировано неоднозначно. Эта практика описана в книге «Discovery: Explore Behaviour Using Examples» (Gáspár & North, 2021) и является обязательной частью BDD-процесса в зрелых командах.

Gherkin-сценарий оформления заказа

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step definitions на Kotlin

Step definitions — это код, связывающий сценарий Gherkin с тестовой реализацией. Каждый шаг — это метод с аннотацией, соответствующей ключевому слову Gherkin.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Интеграция с Cucumber Android

Для запуска BDD-тестов в Android-проекте используется CucumberAndroidJUnitRunner. Он сканирует .feature файлы в ресурсах, находит соответствующие step definitions по регулярным выражениям и выполняет сценарии как обычные инструментальные тесты. Результаты форматируются в HTML-отчёт, понятный заказчику.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

Сложности внедрения BDD в мобильных проектах

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

Поддержка .feature файлов

Основная проблема — рассинхронизация между Gherkin-сценариями и production-кодом. Если разработчики меняют API, не обновляя step definitions, .feature файлы перестают соответствовать реализации. Решение — запускать BDD-тесты в CI/CD пайплайне и требовать зелёного статуса для merge request. Практика «BDD as a gating mechanism» описана в документации Cucumber (2024) и является стандартом в индустрии.

Производительность BDD-тестов

BDD-сценарии на Cucumber выполняются через инструментальные тесты на Android-устройстве или эмуляторе. Это в 10–50 раз медленнее обычных unit-тестов на JVM. Одно приёмочное тестирование может занимать 20–30 минут для крупного Android-приложения. Рекомендуется выделять BDD-тесты в отдельный CI-джоб и запускать их ночью, а unit-тесты — на каждый push. Такая стратегия балансирует скорость обратной связи и покрытие сценариев.

Обучение команды Gherkin

Переход на BDD требует обучения не только разработчиков, но и аналитиков с тестировщиками. Gherkin — простой язык, но написание хороших сценариев требует практики. Типичные ошибки новичков: слишком длинные сценарии (больше 10 шагов), смешивание Given-When-Then, использование технических терминов в бизнес-сценариях. По данным BDD Academy (2024), командам требуется в среднем 4–6 спринтов, чтобы достичь зрелости в написании BDD-сценариев.