Привет, вайб-кодеры! Сегодня мы погрузимся в мир BDD (Behavior-Driven Development) и Gherkin — инструментов, которые помогут вам описывать поведение системы так, чтобы его понимали все: от заказчика до автоматизированных тестов. Забудьте о недопониманиях между командами — с Gherkin ваш тест-кейс станет единым источником правды.
Зачем это нужно
Представьте ситуацию: вы, как вайб-кодер, получили задачу от заказчика. Он видит «качели» одним образом, вы — другим, а тестировщик — третьим. В итоге — долгие переписки, исправления и потеря времени. BDD и Gherkin решают эту проблему, предлагая «вездесущий язык» (Ubiquitous Language), который одинаково понятен всем участникам проекта datafinder.ru. Это позволяет описывать поведение системы в терминах домена, например, «Заказ оплачен», а не «кнопка зелёная» datafinder.ru.
Тест-кейсы, написанные в Gherkin, становятся не просто документацией, а «живой документацией» (living documentation). Они одновременно являются требованиями, тестами и основой для регрессионного тестирования datafinder.ru. Это значит, что каждый сценарий проверяет одно конкретное правило или поведение, что делает его легко читаемым и поддерживаемым datafinder.ru.
Как пользоваться
Основа Gherkin — это простой шаблон Given-When-Then:
Given(Дано): Описывает начальное состояние системы или предусловия. Например, «пользователь загрузил видео длительностью 12 минут».When(Когда): Описывает стимул или действие, которое происходит. Например, «он запускает автонарезку».Then(Тогда): Описывает наблюдаемое поведение или ожидаемый результат. Например, «создаётся минимум 3 клипа формата 9:16».
Для добавления дополнительных условий используются ключевые слова And (И) и But (Но) github.com. Каждый .feature файл начинается с ключевого слова Feature, которое описывает общую функциональность. Внутри Feature находятся Scenario (Сценарии), каждый из которых описывает отдельный проверяемый случай support.smartbear.com.
Вот пошаговый шаблон, который вы можете использовать:
Feature: <Название функциональности>
# Краткое описание: зачем эта фича пользователю.
Scenario: <Короткое имя проверяемой ситуации>
Given <Предусловие — состояние ДО действия>
And <Дополнительное предусловие, если нужно>
When <Одно действие пользователя/системы>
Then <Наблюдаемый ожидаемый результат>
And <Дополнительная проверка>
Scenario Outline: <Проверка на наборе данных с разными параметрами>
Given <Начальное условие>
When <Действие с параметром <параметр1>>
Then <Ожидаемый результат <результат1>>
Examples:
| параметр1 | результат1 |
| значение1 | ожидаемый_итог1 |
| значение2 | ожидаемый_итог2 |
Пример 1 — Автонарезка видео в Shorts
Feature: Автонарезка видео в Shorts
Scenario: Длинное видео успешно нарезается
Given пользователь загрузил видео длительностью 12 минут
When он запускает автонарезку
Then создаётся минимум 3 клипа формата 9:16
And каждый клип содержит русские субтитры
And длительность каждого клипа не превышает 60 секунд
Scenario: Видео короче минимума (край)
Given пользователь загрузил видео длительностью 40 секунд
When он пытается запустить автонарезку
Then показывается подсказка «нужно видео от 1 минуты»
And кнопка «Нарезать» неактивна
Scenario: Сбой обработки (ошибка)
Given видео отправлено на нарезку
When сервис обработки недоступен
Then показывается ошибка с предложением повторить
And исходное видео не удаляется
Пример 2 — Авторизация
Feature: Вход в облако
Scenario: Успешный вход
Given зарегистрированный пользователь с верными данными
When он вводит email и пароль и нажимает «Войти»
Then он попадает в свой аккаунт
And его персональное ядро синхронизируется
Scenario: Неверный пароль
Given зарегистрированный пользователь
When он вводит верный email и неверный пароль
Then показывается «неверный email или пароль»
And он остаётся на экране входа
But конкретная причина (email/пароль) не раскрывается (безопасность)
Для проверки сценариев с различными наборами данных используйте Scenario Outline (или Scenario Template) с таблицей Examples support.smartbear.com. Это позволяет запускать один и тот же сценарий несколько раз, подставляя разные значения из таблицы github.com.
Приёмы, о которых не пишут
- Оракулы для
Then: Для каждого шагаThenзаранее договоритесь, что именно и где вы будете проверять. Это могут быть API-ответы (код, заголовки, схема), записи в базе данных (SQL-инварианты), события в шине (имя, версия, ключ партиции), аудит-логи или метрики datafinder.ru. Например, для API можно проверять HTTP 200 OK и наличие токена доступа qapractices.com. - Теги для трассировки и фильтрации: Используйте теги, такие как
@critical,@api,@AC-…,@RTM-…,@component:…, чтобы связывать сценарии с требованиями, фильтровать их и трассировать в матрице трассируемости требований (RTM) datafinder.ru. - DocString и DataTable: Для компактных наборов входных данных или ожидаемых результатов используйте
DataTable. А для передачи больших объемов данных, таких как JSON-тела запросов/ответов, применяйтеDocStringdatafinder.ru.
Связка с движком
Движки qvib.pro предоставляют готовые правила и роли, которые помогут вам быстрее создавать и автоматизировать BDD-сценарии. Интеграция с такими инструментами, как Cucumber, позволяет превращать ваши Gherkin-сценарии в исполняемый код на различных языках программирования (Java, Kotlin, JS, TS, Python) datafinder.ru. Это значительно ускоряет процесс разработки и тестирования, позволяя вам сосредоточиться на вайб-кодинге, а не на рутинной настройке.
Полная карточка в арсенале: https://qvib.pro/arsenal/roles/test-case/