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

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

С самого первого взгляда Gherkin может показаться очень легким. Достаточно просто создать ряд тестовых шагов, которые будут описывать желаемое поведение проверяемого ПО.

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

Начинающие QA-инженеры, порой, очень сильно страдают от так называемого  «писательского ступора», либо же пробуют создавать сценарии, которые вообще невозможно автоматизировать.

Иногда массовые противоречия заставляют людей по-разному понимать (интерпретировать) тестовые шаги.

Также, бывает так, что тестировщики очень сильно детализируют тестовые шаги, делая такие сценарии максимально сложными для адекватного понимания. Массовое раздражение от Gherkin может даже вылиться в плохую репутацию от BDD.

Качественно писать на Gherkin может быть и сложновато, но возможно.

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

Правило №1: золотое правило Gherkin

Так называемое «золотое правило Gherkin» — очень простая вещь: [highlight dark=”no”]старайтесь обращаться с пользователями так, как вы бы желали, чтобы они обращались с вами.[/highlight]

Другими словами, делайте feature-файлы интуитивно понятными для всех.

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

Условно представим, что проектная команда Х создает сайт для продажи курток. Разберем такой сценарий.

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

• Пользователь хочет купить куртку;
• Когда он покупает куртку;
• Пользователь получает куртку.

Это своего рода ультра-декларативный тестовый сценарий, так как он предоставляет совсем немного полезной информации касательно желаемого поведения.

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

Пользовательскому сценарию также не достает подотчетности — он вообще ничего не говорит об условиях будущего успеха.

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

Теперь можно разобраться с другой понятной крайностью.

Тестовый сценарий: купить ботинки с помощью программы.

• Если логин пользователя  — user0011;
• А пароль пользователя —  password0011;
• Когда пользрватель переходит на сайт;
• Вводит свой пароль и логин;
• Нажимает на кнопку валидации;
• Ждет 5 секунд;
• Отображается каталог ботинок на сайте;
• Находит поле поиска;
• Вводит нужное название модели;
• Жмет на поиск.

Это был пример классического ультра-императивного тестового сценария, ведь он максимально детализирован.

Все тестовые шаги показывают низкоуровневые проверки — нажатие на кнопки, работа с формами и прочее.

Но они максимально перегружают пользователя стеной текста, который банально прячет, но не проясняет ценность тестового сценария.

Такие шаги можно автоматизировать, но совместное взаимодействие максимально затруднено.

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

Правило №2: главное правило BDD

Главное правило BDD — это, своего рода правило один-на-один: [highlight dark=”no”]только один сценарий должен покрывать один функционал, единичное, независимое поведение.[/highlight]

Если вы фокусируетесь только на одном поведении единовременно, это очень выгодно:

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

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

К примеру, есть такой результат для наглядности.

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

• Если пользователь на домашней странице магазина продуктов;
• Вводит в поисковой системе наименование товара Х;
• Ему должна отобразиться страница с результатами;
• Если пользователь ищет товары с изображениями;
• Ему должны отобразиться картинки только для товаров Х.

Такой сценарий демонстрирует сразу два поведения: поиск продуктов и поиск продуктов с картинками. Как раз каждая пара «когда-тогда» описывает оригинальное поведение системы.

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

Эти два правила, что были описаны выше, это практичное руководство для процесса создания качественного Gherkin.

Практикуйтесь, ищите оригинальные конструкции по созданию полезных сценариев и тогда вы никогда не сможете отказаться от Gherkin.