Какие плюсы и минусы метода Given-When-Then?

Метод Given-When-Then (GWT)

Given-When-Then — это формат описания сценариев тестирования и требований, разработанный в рамках методологии Behavior-Driven Development (BDD). Это лучшая практика для документирования требований в виде сценариев на естественном языке.

Структура Given-When-Then

Given (Дано) — предусловия, начальное состояние системы

• Описывает контекст и исходные данные
• Отвечает на вопрос «какова исходная ситуация?»

When (Когда) — действие пользователя или события системы

• Описывает конкретное действие или поведение
• Отвечает на вопрос «что произойдёт?»

Then (Тогда) — ожидаемый результат

• Описывает наблюдаемый результат или эффект
• Отвечает на вопрос «каков результат?»

Пример

Functionality: Авторизация пользователя

Scenario: Успешная авторизация с верными учётными данными
  Given пользователь на странице авторизации
  And в поле email введено значение "user@example.com"
  And в поле пароль введено значение "SecurePass123"
  When пользователь нажимает кнопку "Вход"
  Then пользователь перенаправляется на главную страницу
  And в левом меню отображается имя пользователя
  And в cookie сохраняется токен авторизации

Scenario: Ошибка при вводе неправильного пароля
  Given пользователь на странице авторизации
  And в поле email введено значение "user@example.com"
  And в поле пароль введено значение "WrongPassword"
  When пользователь нажимает кнопку "Вход"
  Then отображается сообщение об ошибке "Неверные учётные данные"
  And пользователь остаётся на странице авторизации
  And поле пароля очищается

Плюсы Given-When-Then

1. Простота и ясность

• Использует естественный язык, понятный как для технических специалистов, так и для бизнеса
• Не требует специальных знаний в программировании
• Легко читается и интерпретируется

2. Коммуникация между участниками

• Сценарии служат основой для общего понимания между аналитиками, разработчиками, тестировщиками и бизнесом
• Уменьшает вероятность неправильного истолкования требований
• Служит живой документацией проекта

3. Тестируемость

• Каждый сценарий можно автоматизировать с помощью Cucumber, Behave, SpecFlow
• Получается набор исполняемых спецификаций
• Сценарии часто переиспользуются как основу для unit и integration тестов

4. Структурированность

• Стандартная структура делает документацию более организованной
• Легче искать и поддерживать сценарии
• Удобно отслеживать покрытие требований

5. Фокусировка на поведении

• Акцент на том, что должна делать система, а не как она это делает
• Помогает выявить бизнес-ценность каждого требования
• Сценарии устойчивы к изменениям реализации

6. Историческая ценность

• Сценарии служат документацией истории решений
• Помогают новым участникам проекта быстро разобраться в системе
• Содержат примеры использования функциональности

Минусы Given-When-Then

1. Излишняя детализация

• Не все требования хорошо укладываются в формат GWT
• Для простых требований может быть перебором
• Увеличивает объём документации

2. Трудность описания сложных сценариев

• Сложные бизнес-логику сценарии трудно описать в одной строке
• Много шагов Given и Then делают сценарий громоздким
• Параллельные процессы сложно отразить

3. Отсутствие деталей реализации

• Сценарий не содержит информацию о том, как реализовать функцию
• Требует дополнительной технической документации
• Может быть недостаточно для сложных интеграций

4. Проблема с обслуживанием

• При изменении требований нужно обновлять все сценарии
• Если сценарии не синхронизированы с кодом, они становятся бесполезными
• Требует дополнительного контроля версионирования

5. Необходимость специальных инструментов

• Для автоматизации нужны Cucumber, Behave и т.п.
• Требует повышения квалификации команды
• Дополнительные затраты на внедрение

6. Проблема с граничными случаями

• Граничные значения и исключительные ситуации трудно описать в GWT
• Может потребоваться множество сценариев для полного покрытия
• Риск упустить нестандартные ситуации

7. Ложное чувство полноты

• Может создавать впечатление полного описания требований
• На самом деле, сценарии часто содержат неявные допущения
• Нужна дополнительная валидация и уточнение

Когда использовать Given-When-Then

Подходит для:

• Бизнес-логики с чёткими правилами
• Требований, где важна коммуникация между бизнесом и IT
• Функциональности, которую часто меняют
• Проектов, где требуется живая документация

Не подходит для:

• Сложных алгоритмических требований
• Низкоуровневых технических спецификаций
• Проектов с жёсткими требованиями и редкими изменениями
• Систем с высокой степенью параллелизма

Лучшие практики

• Каждый сценарий должен проверять одну фичу
• Сценарии должны быть независимы друг от друга
• Используй понятный и специфичный язык
• Избегай технических деталей в сценариях
• Сценарии должны быть автоматизированы и выполняться регулярно
• Поддерживай сценарии в актуальном состоянии вместе с кодом

Given-When-Then — мощный инструмент для сотрудничества и документирования, но требует дисциплины и правильного применения для эффективности.