BDD — совместная работа над поведением продукта через конкретные примеры. Команда уточняет правило до реализации, формулирует понятные примеры и при необходимости автоматизирует их. Cucumber является инструментом выполнения таких спецификаций, а Gherkin — языком их записи.
Эти понятия нельзя считать синонимами. Файл с Given, When и Then ещё не означает, что команда использует BDD. Если QA переписывает готовые технические тесты в Gherkin в одиночку после разработки, появляется дополнительный слой поддержки без главной пользы: согласованного понимания до написания кода.
Начните с разговора о правиле
Возьмите небольшое изменение и соберите владельца продукта, разработчика и QA. Обсудите несколько примеров и контрпримеров. Для правила бесплатной доставки важны порог суммы, состав допустимых товаров, валюта, применённые скидки и момент расчёта.
Неопределённости фиксируют явно. Например, «порог считается до купона или после?» — вопрос к продукту, а не повод молча выбрать вариант в step definition. Обнаруженная неоднозначность уже является полезным результатом работы, даже если ни один сценарий пока не автоматизирован.
Gherkin выражает поведение
Given задаёт существенное исходное состояние, When — событие или действие, Then — наблюдаемый результат. And продолжает предыдущую часть. Сценарий должен объяснять правило без знания селекторов и внутренней структуры приложения.
Техническое описание «нажать зелёную кнопку справа» быстро устаревает и плохо читается владельцем продукта. Формулировка «покупатель оформляет заказ» сохраняет смысл, даже если интерфейс поменялся. При этом важные детали поведения нельзя прятать: способ оплаты или роль могут определять сам результат.
Пример спецификации доставки
Предположим, команда согласовала учебное правило: бесплатная доставка доступна от 10 000 денежных единиц после скидок. Пример ниже является спецификацией; для выполнения в Cucumber понадобятся step definitions выбранного языка и тестовая система заказов.
Feature: Стоимость доставки
Rule: Порог считается после скидок
Scenario Outline: Доставка у границы порога
Given сумма допустимых товаров после скидок равна <amount>
When покупатель рассчитывает доставку
Then стоимость доставки равна <delivery>
Examples:
| amount | delivery |
| 9999 | 500 |
| 10000 | 0 |
| 10001 | 0 |Данные и стоимость здесь иллюстративные. Ожидаемый результат обсуждения — согласованные случаи ниже границы, на границе и выше неё. Отдельно проверяют применение купона, исключённые товары и недоступный регион, если эти условия входят в реальные требования.
Как связать текст с кодом
Step definition сопоставляет текст шага с исполняемым кодом. Он подготавливает состояние, вызывает действие или проверяет результат. Лучше делегировать детали API-клиенту или объектам интерфейса, оставляя шаг понятной границей между спецификацией и механизмом.
Не нужно вызывать один step definition из другого как обычную функцию. Общую логику выделяют ниже уровня шагов. Иначе связь между текстом и реализацией становится трудно прослеживаемой, а изменения формулировки могут неожиданно затронуть несвязанные сценарии.
На каком уровне автоматизировать
Спецификация поведения не обязывает запускать браузер. Расчёт доставки можно проверять через доменный сервис или API, если именно там находится правило. Небольшой сквозной набор отдельно подтверждает, что пользователь может увидеть и использовать результат.
Уровень должен соответствовать цели сценария. Если Then обещает «покупатель видит бесплатную доставку», проверка только функции расчёта недостаточна. Если речь исключительно о тарифном правиле, подробная браузерная матрица добавит стоимость и отвлечёт от смысла примеров.
Scenario Outline и таблицы
Scenario Outline запускает один сценарий с несколькими строками Examples. Он уместен, когда меняются данные, а правило и действия остаются одинаковыми. Таблица не должна скрывать сложные условия или десятки не связанных между собой бизнес-ситуаций.
Data Table внутри шага передаёт структурированные данные одному выполнению, например состав корзины. Это другой механизм. Выбирайте представление, которое легче читать участникам обсуждения, и обеспечивайте понятные названия параметров и единицы измерения.
Состояние и изоляция
Каждый сценарий должен начинаться в известных условиях. Случайный заказ, оставшийся со вчера, делает спецификацию невоспроизводимой. Подготовка создаёт собственные данные и возвращает идентификаторы, а cleanup не должен удалять чужие записи параллельного прогона.
Background подходит для общего существенного контекста, но длинная скрытая подготовка затрудняет чтение. Оставляйте в нём только то, что помогает понять каждый сценарий. Техническую настройку соединения и очистку ресурсов лучше решать средствами выбранного runner.
Как поддерживать живую документацию
Сценарии должны обсуждаться при изменении правил и запускаться достаточно часто. Ссылка на требование и понятный владелец помогают отличать изменившееся ожидание от дефекта. Старые примеры удаляют или переписывают вместе с продуктом.
Критерий полезности — участник команды может прочитать сценарий, объяснить правило и понять последствия падения. Если документы читают только авторы step definitions, стоит пересмотреть язык, детализацию и саму необходимость слоя Gherkin для этой области.
Во время review попросите участника, который не писал реализацию, назвать причину каждого примера. Если два сценария иллюстрируют одно правило без дополнительного риска, их можно объединить. Если между ними спрятано различие ролей или условий, это различие нужно сделать видимым в тексте, а не оставлять в технической подготовке.
Типичные ошибки
Самые частые проблемы: длинные сценарии с десятками действий, технические шаги вместо примеров поведения, неоднозначные регулярные выражения и несколько разных шагов с одинаковым смыслом. Слишком общий шаг вроде «система работает правильно» не даёт наблюдаемого ожидания.
Не измеряйте зрелость BDD числом feature-файлов. Избыточная автоматизация всех формулировок может сделать обсуждение дороже. Некоторые исследовательские вопросы сначала требуют разговора и прототипа, а затем превращаются в стабильные примеры.
Что должен вынести QA
BDD помогает предотвращать недопонимание, а автоматизация сохраняет согласованные примеры проверяемыми. Cucumber и Gherkin поддерживают этот процесс, если команда действительно использует общий язык и совместно владеет правилами.
Начните с одной небольшой истории: обсудите границы, запишите несколько ясных примеров и выберите достаточный уровень исполнения. Затем оцените, стали ли требования понятнее и расследования быстрее. Это более содержательный результат, чем механический перевод каждого теста в Given–When–Then.