Gherkin – это структурированный естественный язык (Natural Language), который используется для описания поведения системы по заданному сценарию. Может использоваться в рамках Agile-практики Behavior Driven Development (BDD), например, в среде (фреймворке) автоматизированного тестирования как Cucumber (или JBehave, RSpec).
В словарь языка включено десять ключевых слов (Given, When, Then, And, But, Scenario, Feature, Background, Scenario Outline, Examples). Более подробно про Agile-практику Given-When-Then см. тут.
Следуя концепции BDD с различными целями Gherkin может использоваться разработчиками, аналитиками и QA-инженерами, например, для написания Acceptance Criteria/Tests.
Это интересно!
Практика BDD входит в так называемый клан (tribe) практик Agile (он называется Testing) для организации процессов гибкого тестирования.
Для глубоко понимающих Agile приведу аналогию c объединением практик в трайб для Scrum, который определяет инструменты уже входящие во фреймворк (Backlog, например) и инструменты, дополняющие гибкую разработку с использованием фреймворка Scrum (Burndown chart, Planning poker, Backlog grooming, например).
Трайб Testing предназначен для обеспечения инструментарием процессов гибкой разработки и гибкого тестирования, которые могут быть реализованы, как с использованием BDD, так и большего количества практик из трайба. Язык Gherkin расширяет шаблон Given-When-Then и является еще более мощным инструментом для реализации BDD.
Бизнес-аналитики могут использовать Gherkin для расширенного описания поведения системы (создания пользовательских требований в виде пользовательских историй (User Stories)).
Например, для несколько упрощенной пользовательской истории:
As a Client
I can Log In
So that I can see my Client page
Можно дать следующее расширенное описание:
Scenario 1.1: Log In is successful
Given Client John tries to Log In
And the Username is valid
And the Password is valid
When the Client presses the button for Log In
Then System displays welcome message
And the Client page appears
Scenario 1.2: Log In is failed
Given Client John tries to Log In
And the Username is not valid
And the Password is valid
When the Client presses the button for Log In
Then System displays message about wrong Username
And the Client page doesn’t appear
Scenario 1.3: Log In is failed
Given Client John tries to Log In
And the Username is valid
And the Password is not valid
When the Client presses the button for Log In
Then System displays message about wrong Password
And the Client page doesn’t appear
Решение о необходимости расширенного описания поведения системы, безусловно, принимается исходя из условий и потребностей конкретного проекта.
Всю серию статей по BDD можно найти в соответствующей рубрике или по тегам, расположенным под статьей.
Для дальнейшего развития ресурса выберите, пожалуйста, варианты ответов в формах ниже и нажмите кнопки «Vote». Спасибо!
Смотрите также:
Добрый день!
Спасибо за комментарий!
По п. 2 согласна.
В п. 3 — да, здесь лучше использовать present simple.
НравитсяНравится
Здравствуйте, не совсем верно.
Сценарий 1.1.:
— лучше использовать переменную вместо «named John».
— button “Log in” — лучше избегать упоминаний title для контролов, т.к. это снижает стабильность тестов и создает зависимость от UI.
— «And the Client page is displayed» Тут лучше использовать present simple, чтобы показать что действие выполняеться непосредственно после WHEN — иначе нужно указать временной лаг.
НравитсяНравится