Автор: Энди Найт (Andy Knight)

Оригинал статьи: http://automationpanda.com/2018/01/31/good-gherkin-scenario-titles/

Перевод: Ольга Алифанова

Золотое правило Gherkin гласит:

"Обращайтесь с читателями так, как вы хотели бы, чтобы обращались с вами. Пишите Gherkin так, что люди, не знающие фичу, поймут, о чем это".

Хороший Gherkin (как и любой язык, основанный на specification-by-example) неразрывно связан с созданием хороших заголовков для поведенческих сценариев. Заголовок – это лицо сценария: он резюмирует суть поведения. Хорошие заголовки серьезно облегчают сотрудничество в команде, а плохие – затрудняют его. Но что же делает заголовок "хорошим"? Вот несколько неплохих советов.

Одна строка

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

Плохой пример:

"Пользователь может авторизоваться в приложении, перейти на страницу профиля и увидеть имя, адрес, телефон, почту и логин".

Хороший пример:

"Страница профиля отображает персональные данные пользователя".

Конъюнкция и дизъюнкция

Следите за соединительными словами вроде "и", "или", и "но". Конъюнкции обычно подразумевают, что будет произведено несколько действий. Для заголовка это означает, что покрыто не единственное поведение. Это может также означать, что информацию лучше поместить в описание сценария. Не нарушайте главное правило BDD! Каждый сценарий должен концентрироваться на одном главном поведении.

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

Плохой пример:

"Пользователь может запросить страховую оценку через большую кнопку "Получить оценку" на домашней странице, или со страницы расчета страховки".

"Последние пять поисковых запросов сохраняются, так чтобы пользователь мог снова их запросить через историю".

Хороший пример:

Два сценария: "Пользователь запрашивает страховую оценку через кнопку "Получить оценку" на домашней странице" и "Пользователь запрашивает страховую оценку со страницы расчета страховки".

ИЛИ

"Описание сценария: пользователь запрашивает страховую оценку".

 "Страница истории сохраняет пять последних поисковых запросов".

Избегайте языка утверждений

Не используйте слова "убедиться", "верифицировать" или "должен" в заголовках сценариев. Они ставят ударение на утверждении, а не на поведении. Утверждения – это просто одна из граней поведенческого тестирования: они верифицируют, что что-то существует, или что два значения равны. Однако поведенческий сценарий – это полноценная спецификация ПО. BDD – это практика разработки, нацеленная на создание более качественных продуктов, а не только инструмент тестирования. Не сводите его исключительно к тестам.

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

Плохой пример:

"Убедитесь, что пользователь может изменить адрес на странице профиля".

"Убедитесь, что стоимость акций отображается зеленым цветом, если она выше, чем стоимость на момент закрытия рынка".

"Прощальная страница должна отображаться после успешного выхода из системы".

Хороший пример:

"Изменение адреса на странице профиля".

"Стоимость акции зеленая, если ее стоимость выше, чем стоимость на момент закрытия рынка".

"После выхода из системы отображается прощальная страница".

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