The post has been translated automatically. Original language: Russian
This is the third part of a series about BDD. ""In the second part, ""Discovery: "three Amigos" and Example Mapping," we collected examples from the discussion. In the fourth, "Automation: Tools and CI," we will turn scenarios into tests.
After the discussion, the team has a set of examples. To avoid leaving them on the stickers, they are recorded in a structured form. The Gherkin language is used for this.
What is Gherkin?
It is a simple language with strict keywords and free text inside. Scripts are stored in files with the extension .feature next to the project code. Gherkin supports different interface languages, including Russian.
Key keywords:
• Function: The name and brief description of what is being tested.
• Scenario: one specific example.
• Given / When/Then: context, action, and expected outcome.
• And / But: continuation of the previous step.
• Background: The general steps that are performed before each scenario.
• Scenario Structure and Examples: one scenario with different datasets.
Example
# language: ru
Function: Applying a promo code
Scenario: A valid promo code reduces the order amount
There are items in the basket in the amount of 10000 tenge
When the user applies a promo code for a 10 discount%
Then the order amount becomes 9,000 tenge
Scenario structure: Different discount sizes
There are products in the basket for the amount of <amount> tenge
When the user applies a promo code for a discount <discount>%
Then the order amount becomes <total> tenge
Examples:
| amount | discount | total |
| 10000 | 10 | 9000 |
| 5000 | 20 | 4000 |
The second scenario shows how not to duplicate the steps: the Examples table turns one template into several checks.
Rules for good scenarios
1. Describe the behavior, not the interface. ""The user applies a promo code" is better than "the user clicks the button in the right corner".
2. One script checks one rule. If there are a lot of "Then" in it, maybe they should be separated.
3. Use specific values. The numbers and states make the example unambiguous.
4. Keep the scenarios short. Three to five steps are usually enough.
5. Write in the language of the subject area. ""The order is completed" is better than "there is an entry in the orders table".
6. Make the scripts independent. The launch order should not affect the result.
7. Name the scenarios so that the name explains the rule. A failed test should immediately tell you what's broken.
Imperative and declarative style
Imperative (bad):
When the user opens the shopping cart page
He enters """PROMO10" in the "Promo Code"
field and clicks the "Apply" button.
Declaratively (good):
When a user applies a promo code for a 10% discountThe declarative style reads like a description of a business rule and does not break when the design is changed. The details (which fields to fill in, which buttons to press) are transferred to the step code.
Result
A good script reads like a short story and verifies one rule. In the fourth part, "Automation: Tools and CI," we'll look at how to link such text to code and run it automatically.
Try writing one function from your project as three scripts. Which turned out to be more difficult: to choose the wording or to agree on the rules?
Это третья часть серии о BDD. Во второй части, «Discovery: “три амиго” и Example Mapping», мы собрали примеры на обсуждении. В четвёртой, «Автоматизация: инструменты и CI», превратим сценарии в тесты.
После обсуждения у команды есть набор примеров. Чтобы они не остались на стикерах, их записывают в структурированном виде. Для этого используют язык Gherkin.
Что такое Gherkin
Это простой язык со строгими ключевыми словами и свободным текстом внутри. Сценарии хранятся в файлах с расширением .feature рядом с кодом проекта. Gherkin поддерживает разные языки интерфейса, в том числе русский.
Основные ключевые слова:
• Функция: название и краткое описание того, что тестируется.
• Сценарий: один конкретный пример.
• Дано / Когда / Тогда: контекст, действие и ожидаемый результат.
• И / Но: продолжение предыдущего шага.
• Предыстория: общие шаги, которые выполняются перед каждым сценарием.
• Структура сценария и Примеры: один сценарий с разными наборами данных.
Пример
# language: ru
Функция: Применение промокода
Сценарий: Действующий промокод снижает сумму заказа
Дано в корзине товары на сумму 10000 тенге
Когда пользователь применяет промокод на скидку 10%
Тогда сумма заказа становится 9000 тенге
Структура сценария: Разные размеры скидки
Дано в корзине товары на сумму <сумма> тенге
Когда пользователь применяет промокод на скидку <скидка>%
Тогда сумма заказа становится <итог> тенге
Примеры:
| сумма | скидка | итог |
| 10000 | 10 | 9000 |
| 5000 | 20 | 4000 |
Второй сценарий показывает, как не дублировать шаги: таблица Примеры превращает один шаблон в несколько проверок.
Правила хороших сценариев
1. Описывайте поведение, а не интерфейс. «Пользователь применяет промокод» лучше, чем «пользователь нажимает кнопку в правом углу».
2. Один сценарий проверяет одно правило. Если в нём много «Тогда», возможно, их стоит разделить.
3. Используйте конкретные значения. Числа и состояния делают пример однозначным.
4. Держите сценарии короткими. Обычно достаточно трёх–пяти шагов.
5. Пишите языком предметной области. «Заказ оформлен» лучше, чем «в таблице orders появилась запись».
6. Делайте сценарии независимыми. Порядок запуска не должен влиять на результат.
7. Называйте сценарии так, чтобы название объясняло правило. Проваленный тест должен сразу говорить, что сломалось.
Императивный и декларативный стиль
Императивно (плохо):
Когда пользователь открывает страницу корзины
И вводит "PROMO10" в поле "Промокод"
И нажимает кнопку "Применить"
Декларативно (хорошо):
Когда пользователь применяет промокод на скидку 10%Декларативный стиль читается как описание бизнес-правила и не ломается при смене дизайна. Детали (какие поля заполнить, какие кнопки нажать) переносятся в код шагов.
Итог
Хороший сценарий читается как короткая история и проверяет одно правило. В четвёртой части, «Автоматизация: инструменты и CI», посмотрим, как связать такой текст с кодом и запускать его автоматически.
Попробуйте записать одну функцию из вашего проекта в виде трёх сценариев. Что оказалось сложнее: подобрать формулировки или согласовать правила?
Share
