Home

Автор: Энди Найт (Andy Knignt)
Оригинал статьи
Перевод: Ольга Алифанова

Разработка через реализацию поведения (BDD) может помочь команде создавать хорошее ПО через скрупулезную спецификацию поведения продукта на простом языке. Неважно, хотите ли вы улучшить сотрудничество через встречу "трех друзей", или повысить качество автоматизации при помощи фреймворка вроде Cucumber – в центре BDD стоит один язык: Gherkin.

С первого взгляда Gherkin выглядит простым – просто напишите ряд шагов, описывающих желаемое поведение. Однако я сталкивался с командами, которым очень трудно хорошо писать на Gherkin. Начинающие часто страдают от писательского ступора, или же пишут сценарии, которые сложно автоматизировать. Иногда противоречивость заставляет людей по-разному интерпретировать шаги. Еще, бывает, люди слишком детализируют шаги, делая сценарии сложными для понимания. Раздражение от Gherkin даже выливается в плохую репутацию BDD.

Хорошо писать на Gherkin, возможно, сложно, но это не невозможная задача. Вот четыре правила, которые помогут вам писать на Gherkin читабельно, автоматизируемо, и масштабируемо.

1. Золотое правило Gherkin

Золотое правило Gherkin простая штука: обращайтесь с читателями так, как вы бы хотели, чтобы обращались с вами. Если конкретнее, то пишите фича-файлы так, чтобы они были интуитивно понятными. Хороший Gherkin должен улучшать сотрудничество команды, проясняя поведения, которые вам нужно разработать. Когда Gherkin тяжело читать, сложно хорошо проработать нужное поведение.

Допустим, ваша команда разрабатывает веб-сайт для магазина обуви. Возьмем такой сценарий:

Сценарий: Туфли

- Если я хочу туфли

- Когда я покупаю туфли

- Я получаю туфли.

Это ультра-декларативный сценарий, потому что он дает недостаточно информации о желаемом поведении. Он слишком расплывчатый. Какие туфли? Как их заказать? Как проверить заказ? Это часть юзер-стори, а не спецификации. Сценарию также не хватает подотчетности – он ничего не говорит о внятных условиях успеха. Как правило, к ультра-декларативным сценариям больше склонны продакт-оунеры, потому что они плохо знакомы с автоматизацией.

Разберем другую крайность:

Сценарий: Заказ туфель через приложение.

- Если мой логин jessica8494

- И мой пароль PleaseDontPutSecretsInGherkin

- Когда я перехожу в браузере на www.shoestore.com

- И ввожу свой логин в поле логина

- И ввожу свой пароль в поле пароля

- И нажимаю на кнопку логина

- И жду десять секунд

- Тогда отображается домашняя страница Магазина Обуви

- И верхний баннер содержит текст "Магазин Обуви"

- И корзина пуста

- Когда я нажимаю на панель поиска

- И ввожу "красные шпильки" в строку поиска

- И жду 30 секунд

- Тогда отображается страница результатов поиска

- И она показывает 10 результатов на страницу

- И…

Это ультра-императивный сценарий, так как он чересчур детализирован. Все шаги описывают ручные, низкоуровневые взаимодействия – нажатия кнопок, ожидания. Они перегружают пользователя стеной текста, который прячет, а не проясняет ценность сценария. Автоматизировать можно каждый шаг, но совместная работа тут затруднена.

Если бы вы были в этой команде, хотели бы вы иметь дело с любым из этих сценариев? Конечно, нет, потому что ни один из них не помогает построению нужного поведения. Вот как это пишется:

Сценарий: Добавление туфель в корзину

- Если открыта домашняя страница магазина обуви

- Когда пользователь ищет "красные шпильки"

- И пользователь добавляет первый результат в корзину

- Тогда в корзине появляется одна пара "красных шпилек"

У этого сценария внятные, описательные шаги. Шаги четко следуют порядку "Если – Когда – Тогда", который демонстрирует настройку, взаимодействие и верификацию желаемого поведения. Сценарий использует "красные шпильки" в качестве конкретного примера для лучшего понимания сценария. Он краток, но непротиворечив. Это куда лучше, чем предыдущие варианты.

Если вы не уверены, что не пишете чересчур декларативные или императивные сценарии, вспомните о Золотом Правиле Gherkin. Какой сценарий вам захотелось бы прочитать?

2. Главное правило BDD

Главное правило BDD – это правило один-на-один: один сценарий должен покрывать одно, единичное, независимое поведение. Когда вы фокусируетесь на одном поведении единовременно, это выгодно:

• Сотрудничество: больше концентрации, меньше путаницы.
• Автоматизация: падение каждого теста конкретно указывает на проблему.
• Эффективность: менее сложная работа ускоряет рабочий цикл.
• Отслеживаемость: Одно поведение – Один пример – Один сценарий – Один тест – Один результат.
• Прозрачность: Команды не могут прятать или избегать поведений.

К счастью, заметить, что сценарий покрывает больше одного поведения, очень легко. Возьмем вот такой:

Сценарий: Простой поиск продукта.

- Если открыта домашняя страница магазина обуви

- Когда введена поисковая фраза "красные шпильки"

- Тогда выдается результат для "красных шпилек"

- Когда пользователь ищет изображения со страницы результатов

- Тогда выдаются изображения для "красных шпилек"

Этот сценарий покрывает два разных поведения: поиск туфель, и поиск изображений обуви. Каждая пара "когда-тогда" описывает уникальное поведение. Если в сценарии более одной такой пары, он по определению покрывает несколько разных поведений. К счастью, их легко разделить:

Сценарий: Простой поиск продукта.

- Если открыта домашняя страница магазина обуви

- Когда введена поисковая фраза "красные шпильки"

- Тогда выдается результат для "красных шпилек"

Сценарий: Простой поиск веб-изображений.

- Если открыт результат поиска для "красных шпилек"

- Когда введена поисковая фраза "красные шпильки"

- Тогда выдается результат для "красных шпилек"

Конец первого сценария можно использовать как "если"-шаг для второго сценария. В этом случае второй сценарий сосредоточен только на одном-единственном поведении. Можно также использовать автоматизацию для оптимизации этого "если"-шага, сокращая маршрут при помощи прямой ссылки.

3. Правило уникального примера

Иногда меньше – это лучше, поэтому не нужно излишних примеров. Лучше сконцентрируйтесь на уникальных классах эквивалентности. Идея "протестировать все" очень привлекательна, но мы теряем ценное время – вместо этого тестируйте самое важное и избегайте тестирования дубликатов.

Возьмем вот такой сценарий:

Шаблон сценария: Простой поиск продукта.

- Если открыта домашняя страница магазина обуви

- Когда введена поисковая фраза "(поисковая фраза)"

- Тогда выдается результат для "(поисковой фразы)"

Примеры: Туфли

- красные шпильки

- кроссовки

- сандалии

- флип-флопы

- плоская подошва

- тапочки

- беговая обувь.

Сценарий запускается один раз для каждого примера, и этот шаблон запустится семь раз. Если обычный тест UI занимает минуту, то каждый прогон добавит много времени к тест-набору. Все эти примеры просто покрывают различные типы обуви. Скорее всего, "обувь" – само по себе класс эквивалентности, и тестировать разные виды обуви может быть бессмысленным. Всегда подходите к примерам с умом.

4. Правило хорошей грамматики

Язык – это важно, поэтому пишите так, как будто это будет оценивать ваша учительница английского языка. Поведенческие сценарии должны быть читабельными и ясными. Шаги должны быть переиспользуемыми. Плохая грамматика, опечатки, обрывочные фразы разрушат все достоинства поведенческой спецификации. Сценарии станут запутанными, и члены команды будут использовать вырванные из контекста шаги.

Одна из самых больших языковых проблем с Gherkin – это когда сценарии не соответствуют друг другу. Шаги можно писать от первого (я, мне, мой) или третьего (пользователь) лица. Я обеими руками за запись от третьего лица для Gherkin-шагов, но куда важнее использовать или то, или другое, и только его. Смотрите, что произойдет при смешении:

Сценарий: Простой поиск продукта.

- Если я нахожусь на домашней странице магазина обуви

- Когда пользователь ищет "красные шпильки"

- Тогда я вижу ссылки на страницы "красных шпилек"

Сценарий ясен, но выглядит неряшливым. Его смысл тоже может быть противоречив – я пользователь, или есть какой-то еще пользователь? Используйте одну форму глагола для единообразия.

Плохая формулировка шагов – еще одна частая проблема. Ваши шаги должны использовать полные предложения, как будто вы пишете обычный текст. Представьте такие шаги:

- И ссылки на картинки "кроссовок"

- И ссылки на видео "кроссовок"

Если вырвать их из контекста, эти шаги противоречивы. Они нажимают на ссылки? Они убеждаются в существовании ссылок? Они просто описывают подлежащее, но не сказуемое. Эта противоречивость вызовет проблемы, когда команда будет создавать и автоматизировать новые сценарии. Проясните их:

- И страница результатов отображает ссылки на картинки "кроссовок"

- И страница результатов отображает ссылки на видео "кроссовок"

Третья проблема, с которой часто сталкиваюсь, связана с временами – прошлым, настоящим и будущим. Каждый тип шагов должен следовать внятным правилам внутри единого решения. Я рекомендую делать так:

• Шаги "Если" должны использовать прошедшее время, потому что они описывают состояние, которое уже должно быть создано.
• Шаги "Когда" должны использовать настоящее время, потому что описывают действия, активно выполняющиеся как часть поведения.
• Шаги "Тогда" должны использовать настоящее или будущее время, потому что описывают, что произойдет после поведенческих действий.

Повторение – мать учения

Правила, которые я описал, должны стать вашим руководством по созданию хорошего Gherkin. Я бы мог написать много всего про форматирование, длину строки и выбор слов, но это вторично по отношению к хорошим принципам. Попробуйте, и успехов с Gherkin!

Обсудить в форуме