Подписаться

BDD тестирование.
Язык Gherkin.
Фреймворк Cucumber.

BDD тестирование.
Язык Gherkin.
Фреймворк Cucumber.

Smartiqa Article
  • Дата: 10 марта 2022
  • Автор: Евгений Поваров

1. Что такое TDD?

“
Разработка через тестирование (англ. Test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам.
Какие основные принципы?
  1. Тесты пишутся непосредственно перед написанием самого кода.
  2. Среда разработки должна быстро реагировать на небольшие модификации кода.
  3. Архитектура программы должна базироваться на использовании множества сильно связанных компонентов, которые слабо сцеплены друг с другом, благодаря чему тестирование кода упрощается.

Рассмотрим более подробно основные преимущества TDD концепции:
  1. Влияние на интерфейс программы. Разработка через тестирование предлагает больше, чем просто проверку корректности, она также влияет на дизайн программы. Разработчик продумывает детали интерфейса до реализации.
  2. Сокращение общего времени на разработку. Несмотря на то, что при разработке через тестирование требуется написать большее количество кода, общее время, затраченное на разработку, обычно оказывается меньше. Поэтому время, затрачиваемое на отладку, снижается многократно.
  3. Беспроблемный рефакторинг. Тесты позволяют производить рефакторинг кода без риска его испортить. Если новая функциональность приводит к ошибкам, тесты сразу же это покажут.
  4. Обеспечение документации. Тесты могут использоваться в качестве документации. Хороший код расскажет о том, как он работает, лучше любой документации, особенно если учесть тот факт, что документация и комментарии в коде могут устаревать

Недостатки TDD:
  1. Неполная покрываемость задач. Существуют задачи, которые невозможно (по крайней мере, на текущий момент) решить только при помощи тестов. В частности, TDD не позволяет механически продемонстрировать адекватность разработанного кода в области безопасности данных и взаимодействия между процессами. Кроме того, разработку через тестирование сложно применять в тех случаях, когда для тестирования необходимо прохождение функциональных тестов. Примерами может быть: разработка интерфейсов пользователя, программ, работающих с базами данных, а также того, что зависит от специфической конфигурации сети. TDD сосредотачивается на тестировании отдельно взятых модулей.
  2. Увеличение сложности тестов во временной перспективе. Уровень покрытия тестами, получаемый в результате разработки через тестирование, не может быть легко получен впоследствии. Исходные тесты становятся всё более ценными с течением времени. Если неудачные архитектура, дизайн или стратегия тестирования приводят к большому количеству непройденных тестов, важно их все исправить в индивидуальном порядке. Простое удаление, отключение или поспешное изменение их может привести к необнаруживаемым пробелам в покрытии тестами.
  3. Человеческий фактор. Модульные тесты, создаваемые при разработке через тестирование, обычно пишутся теми же, кто пишет тестируемый код. Если разработчик неправильно истолковал требования к приложению, и тесты будут содержать ошибки.
  4. Материальные и временные затраты. Требуется больше времени на разработку и поддержку, а одобрение со стороны руководства очень важно. Если у организации нет уверенности в том, что разработка через тестирование улучшит качество продукта, то время, потраченное на написание тестов, может рассматриваться как потраченное впустую. Тесты сами по себе являются источником накладных расходов.

2. Что такое BDD?

“
BDD (сокр. от англ. Behavior-driven development, дословно «разработка через поведение») — это методология разработки программного обеспечения, являющаяся ответвлением от методологии разработки через тестирование (TDD). Основной идеей данной методологии является совмещение в процессе разработки чисто технических интересов и интересов бизнеса, позволяя тем самым управляющему персоналу и программистам говорить на одном языке. Для общения между этими группами персонала используется предметно-ориентированный язык, основу которого представляют конструкции из естественного языка, понятные неспециалисту, обычно выражающие поведение программного продукта и ожидаемые результаты.
На что обратить внимание?
  1. Концепция BDD - есть расширение методологии TDD.
  2. Тесты пишутся на предметно-ориентированном языке, их легко изменять.
  3. Тесты становятся доступны как программистам и тестировщикам, так и менеджерам.
  4. Тесты не зависят от целевого языка программирования. Миграция на другой язык сильно упрощается.

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

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

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

BDD фокусируется на следующих вопросах:
  1. С чего начинается процесс.
  2. Что нужно тестировать, а что нет.
  3. Сколько проверок должно быть совершено за один раз.
  4. Что можно назвать проверкой.
  5. Как понять, почему тест не прошёл.

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

Описание приемочных тестов должно вестись на гибком языке пользовательской истории. В настоящее время в практике BDD устоялась следующая структура:
1) Заголовок (англ. Title). В сослагательной форме должно быть дано описание бизнес-цели.

2) Описание (англ. Narrative). В краткой и свободной форме должны быть раскрыты следующие вопросы:
  1. Кто является заинтересованным лицом данной истории;
  2. Что входит в состав данной истории;
  3. Какую ценность данная история предоставляет для бизнеса

3) Сценарии (англ. Scenarios). В одной спецификации может быть один и более сценариев, каждый из которых раскрывает одну из ситуаций поведения пользователя. Каждый сценарий обычно строится по одной и той же схеме:
  1. Начальные условия (одно или несколько);
  2. Событие, которое инициирует начало этого сценария;
  3. Ожидаемый результат или результаты.

3. Язык Gherkin

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

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

На что обратить внимание?
  1. Структура документа задается отступами.
  2. Каждый шаг начинается с ключевого слова.
  3. Новый шаг - новая строка.

Рассмотрим основные ключевые слова языка Gherkin:
Примерная структура истории:
Пример истории 

История: Короткое описание требуемого функционала  → Заголовок
 
   В роли определенного участника взаимодействия с системой
   Чтобы достичь определенных целей                → Описание
   Я хочу получить определенную пользу
 
   Сценарий: Какая-то определенная бизнес-ситуация → Сценарий
      Допустим какое-то условие
         И ещё одно условие
      Когда предпринимается какое-то действие участником
         И им делается ещё что-то
         И вдобавок он совершил что-то ещё
      Тогда получается какой-то проверяемый результат
         И что-то ещё случается, что мы можем проверить
Рассмотрим каждый из блоков подробнее:

3.1. Заголовок
Структура заголовка выглядит следующим образом:
Feature (История): [Имя истории]
На что обратить внимание?
  1. Имя истории пишется в сослагательной форме после двоеточия.
Example (Feature) 

Feature: Login
История: Вход в приложение
3.2. Описание
Обычно история описывается в следующем формате:
As a (Как) [ человек, который получает выгоду от функциональности ]
In order to (Чтобы достичь) [ выгода от функциональности ]
I want to (Я хочу) [ функциональность ]
На что обратить внимание?
  1. Эти три строки описания истории не интерпретируются программным кодом.
  2. Они являются общепринятым шаблоном, которому, однако, необязательно следовать при написании спецификаций.
Example (Description) 

As a user
In order to pay online
I want to log in
 
Как пользователь
Чтобы совершить платеж онлайн
Я хочу войти в свой аккаунт
3.3. Сценарии
Примерная структура сценария:
Scenario (Сценарий): [ Имя сценария ]
Given (Допустим) [ первое начальное условие ]
And (И) [ второе начальное условие ]
When (Когда) [ событие-инициатор ]
Then (Тогда) [ результат ]

Сценарий начинается с задания начального состояния — предусловия. Оно может состоять из одного пункта, или сразу нескольких, и в Gherkin следует за ключевым словом Given. После чего описываются действия, совершающиеся в ходе сценария — в Gherkin они следует за ключевым словом When. И, наконец, описывается ожидаемый результат, в одном или нескольких пунктах Then.

На что обратить внимание?
  1. Имя сценария так же пишется в сослагательной форме после двоеточия.
  2. Каждая строка представляет собой шаг.
  3. Каждый шаг соответствует одному из методов программного кода.
  4. Если шагов в блоках Given, When или Then несколько, то каждый из них записывается с новой строки и следует за ключевым словом And или But.
Example (Scenario) 

Given User is on Login Page
When User enters login 'user_login'
   And User enters password 'user_password'
Then ‘Welcome to our site’ message displayed
 
 
Допустим пользователь находится на странице логина
Когда пользователь вводит логин 'user_login'
   И пользователь вводит пароль 'user_password'
Тогда появляется сообщение ‘Welcome to our site’
Использование Gherkin удобно по ряду причин:
  1. Сценарии, определяющие поведение системы, описываются в простой форме и могут быть понятны всем участникам проекта.
  2. Файлы, содержащие в себе спецификации, одновременно являются и исполняемыми автотестами.
  3. Тестовая документация и программный код автотестов хранятся в одном проекте и неотделимы друг от друга.
  4. Наличие словаря доступных шагов допускает вариантивность сценариев и позволяет тестировщикам составлять новые автотесты, не обращаясь к программному коду.

4. Фреймворки в BDD

Полуформальный формат спецификации BDD требует использования ограниченного набора предложений, о которых управляющий персонал и разработчики должны предварительно договориться. Исходя из этого, фреймворки для поддержки BDD строятся по следующим принципам:
  1. Парсер может разбить спецификацию по её формальным частям, например по ключевым словам языка Gherkin. На выходе мы получаем набор предложений, каждое из которых начинается с ключевого слова.
  2. Каждое предложение может выражать один шаг теста.
  3. Некоторые части предложения могут являться входными параметрами, которые можно захватить, а остальные части могут никак не использоваться и служить только для понимания действия человеком. Обычно для такого захвата используется процессор регулярных выражений. Захваченные параметры могут быть переконвертированы и отправлены на вход конкретной исполняющей функции.

Список фреймворков, основанных на Gherkin:
На что обратить внимание?
1. Cucumber относится к кроссплатформенным фреймворкам.

Читайте также

Курс. Программирование на Python.
'Программирование на Python' - бесплатный онлайн курс для начинающих из 6 уроков с лекциями, видео, слайдами и домашними заданиями.
Курс. Работа с Git.
Бесплатный курс по работе с самой популярной системой контроля версий - Git: 6 уроков с иллюстрациями, видео и заданиями.

5. Cucumber

5.1. Cucumber. Feature-файлы и сценарии.

Cucumber – это фреймворк, реализующий подход BDD. Соответственно, в Cucumber для написания тестов используется Gherkin-нотация, которая определяет структуру теста и набор ключевых слов:
  1. Тест записывается в файл с расширением .feature и может содержать как один, так и более сценариев.
  2. Строки комментариев допускаются в любом месте .feature файла. Комментарий начинается с символа #.

Рассмотрим более подробно, как язык Gherkin реализован в Cucumber фреймворке.

5.1.1. Ключевые слова
Основные:
  1. Feature / История
  2. Scenario / Сценарий
  3. Given, When, Then, And, But / Дано, Когда, Тогда, И, Но
  4. Background / Предыстория
  5. Scenario Outline (or Scenario Template) / Сценарий-аутлайн

Как видим, первые три пункта относятся к стандартной нотации Gherkin. В свою очередь 4. Background и 5. Scenario Outline добавлены уже в Cucumber. Рассмотрим их подробнее:

4. Background / Предыстория
Часто получается, что одни и те же Given шаги повторяются во всех сценариях в рамках feature-файла. И то, что они повторяются в КАЖДОМ сценарии, говорит о том, что они не так принципиальны относительно КОНКРЕТНОГО сценария. Поэтому такие Given шаги можно вынести отдельно и сгруппировать в секции Background.

Background секция:
  1. может содержать один или несколько Given степов.
  2. выполняется перед КАЖДЫМ сценарием.
  3. только одна в рамках одного .feature файла.
Background Example 

Background: 
  Given user inserts credit card into ATM
      And PIN-code is required 
 
Предыстория:
Допустим пользователь вставляет в банкомат банковскую карту
   И банкомат выдает сообщение о необходимости ввода PIN-кода
5. Scenario Outline / Сценарий-аутлайн
Ключевое слово Scenario Outline используется для выполнения одного и того же сценария несколько раз, но с разными комбинациями параметров.

На что обратить внимание?
  1. Сценарий один и тот же, то есть в нем один и тот же набор шагов.
  2. Параметры шагов разные.
Scenario Outline Example 

Scenario Outline: Cash withdrawal
   When user selects <exchange> option
   Then ATM should issue <quantity> banknotes
 
Examples:
    | exchange | quantity |
    | large    | 1        |
    | small    | 5        |
 
 
Сценарий-аутлайн: Снятие наличных
   Когда пользователь выбирает опцию <размен>
   Тогда банкомат выдает <количество> купюр
 
Примеры:
    | размен   | количество |    ---> Заголовок
    | крупными | 1        |
    | мелкими  | 5        |
На что обратить внимание?
  1. Шаги включают <> параметры, которые соотносятся в заголовком Examples таблицы.
  2. Первая строка Examples секции указывает имена параметров, чьи конкретные значения далее указываются в соответствующих столбцах.
  3. Scenario Outline выполняется один раз для каждой строки в Examples(исключая строку-заголовок).
  4. Cucumber заменяет параметры в шагах на их конкретные значения из таблицы.
  5. Scenario Outline обязательно должен включать Examples секцию.
5.1.2. Вспомогательные ключевые слова
Виды:
  1. Многострочные данные: """
  2. Данные в табличном формате: |
  3. Тэги: @
  4. Комментарии: #

Рассмотрим пример .feature файла, содержащего Cucumber тест, который включает
  1. Background и Scenario Outline секции
  2. Данные в табличном формате, тэги и комментарии
Feature example 

# language: en                             → Комментарий
@all                                       → Тэг 
Feature: Credit card authentication        → Заголовок
ATM should ask for PIN-code                → Описание
ATM should ward user in case PIN-code is incorrect
Authentication is successful if PIN-code is correct
 
Background:                                → Предыстория
Given user inserts credit card into ATM
And ATM asks for PIN-code
 
@correct                                   → Тэг
Scenario: Successful authentication        → Сценарий
When user enters correct PIN-code          → Шаг
Then ATM displays available money          → Шаг
 
@fail                                      → Тэг
Scenario: Failed authentication            → Сценарий
When user enters incorrect PIN-code   → Шаг
Then ATM displays message about incorrect PIN-code
 
Scenario Outline: Cash withdrawal
When user selects <exchange> option
Then ATM should issue <quantity> banknotes
Examples:
    | exchange | quantity |
    | large    | 1        |
    | small    | 5        |


# language: ru                                  → Комментарий
 
@all                                            → Тэг 
История: Аутентификация банковской карты        → Заголовок
Банкомат должен спросить PIN-код карты      → Описание
Банкомат должен выдать предупреждение если код неверный
Аутентификация успешна если если код правильный
 
Предыстория:                                    → Предыстория
Допустим пользователь вставляет в банкомат карту
И банкомат выдает сообщение о необходимости ввода PIN
 
@correct                                        → Тэг
Сценарий: Успешная аутентификация               → Сценарий
Если пользователь вводит корректный PIN-код      → Шаг
То банкомат отображает количество доступных денег
 
@fail                                           → Тэг
Сценарий: Некорректная аутентификация           → Сценарий
Если пользователь вводит некорректный PIN-код      → Шаг
То банкомат оповещает, что введённый код неверный


Сценарий Темплейт: Снятие наличных
Когда пользователь выбирает опцию <размен>
Тогда банкомат выдает <количество> купюр
Примеры:
    | размен    | количество |
    | крупными  | 1        |
    | мелкими   | 5        |

Читайте также

Задачник. Программирование на Python.
Сборник задач с решениями по программированию на языке Python. Темы: Целые числа, Числа с плавающей точкой, Словари, Кортежи, Множества, Списки, Строки, Функции, Циклы for и while, Условные выражения if else, Импорт, Модули и пакеты, ООП Классы и объекты, Файлы, Итераторы.

5.2. Cucumber. Шаги.

Итак, что же из себя представляют Cucumber шаги?

1) Описание шагов
Определение шага (Step Definition) - это блок кода, содержащий выражение, которое сопоставляет его с Gherkin-шагом. Когда по ходу сценария Cucumber исполняет степ, он ищет подходящий Step Definition для выполнения. Рассмотрим следующий сценарий:
Scenario - Login

Scenario: Login
   Given User enters login 'user_login'
В данном случае шаг User enters login 'user_login' будет сопоставлен следующему определению шага:
Step Definition 

Given /^User enters login '(.+)'$/ do |login_word|
   enter(login_word)
end
На что обратить внимание?
  1. Технически сопоставление происходит посредством регулярного выражения /^User enters login '(.+)'$/ , которое и находится в Step Definition.
  2. Логин пользователя (он же захваченный параметр 'user_login') передается в переменную login_word. Она в свою очередь передается на вход функции enter().

2) Результаты шагов
Исполнение каждого шага завершается в одним из следующих статусов:
  1. Success
  2. Undefined
  3. Pending
  4. Failed Steps
  5. Skipped
  6. Ambiguous

Рассмотрим каждый более детально:
1) Success
В случае, если Cucumber находит нужный Step Definition, он запускает выполнение содержимого шага. Если блок кода в соответствующем Step Definition не выдает ошибок по ходу исполнения, шаг помечается как успешный.
Цвет: зеленый

2) Undefined
Если Cucumber не удается найти соответствующее определение шага, то степ помечается как неопределенный и все последующие шаги в сценарии будут пропущены.
Цвет: желтый

3) Pending
Если определение шага выполнено не полностью, то шаг помечается как в ожидании.
Цвет: желтый

4) Failed Steps
Если блок кода внутри Step Definition завершается с ошибкой, то шаг считается проваленным.
Цвет: красный

5) Skipped
Шаги, следующие за Undefined, Pending и Failed степами, не вызываются.
Цвет: голубой

6) Ambiguous
Чтобы Cucumber точно знал, какой блок кода ему вызывать, определение шага должно быть строго уникальным. Cucumber возвращает Cucumber::Ambiguous error, в случае если присутствуют неоднозначные Step Definitions.

3) Организация хранения шагов

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

Технически абсолютно неважно, как будут называться эти файлы, и какие шаги будут в них храниться. Однако существует рекомендация называть их *_steps.rb (если используется Ruby).
Например, в приложении для резюме будет уместно выделить следующие файлы:
Cucumber files 

employee_steps.rb
education_steps.rb
experience_steps.rb
Важно
1. Необходимо всегда помнить, что Cucumber - это только обертка вокруг языка программирования.
2. И рекомендуется не перегружать Step Definitions логикой, а выносить ее в методы-хелперы, которые в свою очередь хранятся в отдельном файле/файлах. Это позволит многократно использовать эти методы другими шагами и упростит понимание структуры проекта. Пример удачного определения степа:
Step example 

Given /^User enters login '(.+)'$/ do |login_word|
   enter(login_word)
end
Чем он хорош? В определении вызывается метод-хелпер enter(). Его логика скрыта от нас внутри определения самого метода и не перегружает излишними техническими подробностями Step Definition.

5.3. Cucumber. Тэги.

Тэги в Cucumber предоставляют отличную возможность грамотно организовать работу с отдельными фичами и сценариями.

На что обратить внимание?
  1. Фича/сценарий могут иметь сколько угодно тэгов. Тэги разделяются пробелами.
  2. Тэги могут располагаться только над следующими элементами: Feature, Scenario и Scenario Outline. И соответсвенно, к секции Background или шагам (Given, When, Then, And и But) они относиться не могут.
  3. Тэги наследуются дочерними элементами. Например, тэг, размещенный над фичей, будет относиться к каждому сценарию и Scenario Outline, внутри этой фичи.

Рассмотрим пример:
Tags example 

@all
Feature: Feature 1
 
@tag1 @tag3 @tag4
Scenario: Scenario 1
Given ...
 
@tag2
Scenario: Scenario 2
Given ...
 
@tag5
Scenario: Scenario 3
Given ...
В данном случае к первому сценарию относятся 4 тэга: один наследуется от Feature(@all) и еще три указаны непосредственно над самим сценарием (@tag1 @tag3 @tag4). Соответственно, ко второму сценарию относятся только два тэга: один по-прежнему наследуется от Feature(@all) и второй @tag2 от самого сценария.

Тэги можно комбинировать. Комбинация тегов представляет собой обычное булево выражение:
Зачем все это нужно? Как правило, в рабочем проекте содержится достаточно большое количество .feature файлов, в каждом из которых содержится по несколько сценариев и аутлайнов. Тэги позволяют Cucumber выбрать только необходимые в данном запуске фичи и сценарии. Т. е. возвращаясь к сценарию выше, можно запустить Cucumber со следующими параметрами: cucumber --tags "@tag1 and @tag5". Что в свою очередь запустит только сценарии 1 и 3, сценарий 2 будет пропущен.

5.4. Cucumber. Хуки.

Хуки (Hooks) - это блоки кода, которые могут запускаться на различных этапах запуска теста. Как правило, они часто используются для настройки окружения перед или после каждого сценария. Хуки обычно хранятся по следующим путям: features/support/env.rb или features/support/hooks.rb.

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

5.4.1. Хуки сценариев (Scenario hooks)
Запускаются для каждого сценария. Делятся на:
  1. Before
  2. After

1) Before хуки
Запускаются перед первым степом каждого сценария. Пример:
Before hook example 

Before do
# Do something before each scenario
end
На что обратить внимание?
  1. К Before хукам необходимо относиться с определенной долей осторожности. Для человека, который видит только feature файл, вся логика, которая лежит внутри хука, остается скрытой.
  2. Если есть возможность вместо Before хука добавить Background секцию внутри feature файла - воспользуйтесь ею.
  3. Старайтесь использовать Before хуки только для низкоуровневой логики. Например, они хорошо подойдут для запуска браузера или удаления данных из БД.

2) After хуки
Запускаются после последнего степа каждого сценария, даже если шаги завалились, в ожидании или пропущены. Пример:
After hook example 1 

After do |scenario|
end
Параметр 'scenario' опционален, однако его использование позволяет получить статус текущего сценария. Например, можно резко прекратить исполнение Cucumber на первом же упавшем сценарии (в общем случае должен просто запуститься следующий сценарий). Например, это может быть необходимо в случае Непрерывной Интеграции (Continuous Integration), когда важен оперативный фидбек в случае проблемы:
After hook example 2 

After do |s|
    Cucumber.wants_to_quit = true if s.failed?
end
5.4.2. Хуки шагов (Step hooks)
Запускаются по аналогии с Before и After хуками, но работают в рамках степов. Так же делятся на:
  1. BeforeStep
  2. AfterStep
Step hook example 

AfterStep do |scenario|
end
5.4.3. Глобальные хуки (Global hooks)
Глобальные хуки запускаются единожды перед запуском тестового набора.

5.5. Cucumber. Конфигурация.

Параметры, с которыми запускается Cucumber можно указать внутри проекта. Для описания конфигурации используются YAML файлы и хранятся они либо в глобальной .config директории, либо в config папке текущего проекта. Формат следующий:
Configuration file format 

имя_профиля_1: параметры
имя_профиля_2: параметры
При этом стоит иметь в виду, что скорее всего тесты будут чаще запускаться с каким-то одним профилем. Поэтому в Cucumber предусмотрен профиль по умолчанию. И в случае если никакой другой профиль при запуске не указан, Cucumber будет использовать default-профиль. Пример YAML файла с конфигурацией:
Configuration file example 

default: --profile html_report 
html_report: --format progress --format html --out=features_report.html
smoke: --tags @smoke
Соответственно, имеем 3 профиля:
  1. default, вызывающий html_report профиль.
  2. html_report со списком параметров командной строки Cucumber, которые задают определенный формат вывода.
  3. smoke, запускающий все фичи и сценарии с тэгом @smoke.

5.6. Cucumber. Примерная структура проекта.

Существуют определенные правила, в соответствии с которыми строится файловая структура проекта на Cucumber. Это делается,
  1. так как по-умолчанию Cucumber ожидает найти файлы определенного типа в папках с определенными названиями.
  2. чтобы не смешивать файлы конфигураций, фича-файлы, определения степов и хуки.
  3. чтобы отделить файлы со сценариями тестов (это файлы Cucumber с расширением .feature ) от файлов реализации методов, которые вызываются в степах(это файлы, содержащие код на конкретном языке программирования, например, Ruby).

Рассмотрим пример:
Project structure 

├── config
│   └── cucumber.yml
├── features
│   ├── smoke.feature
│   ├── step_definitions
│   │   └── steps.rb
│   └── support
│       ├── env.rb
│       ├── hooks.rb
├── lib
│    ├── city_helper.rb
│    ├── http_api_helper.rb
       └── selenium_helper.rb
На что обратить внимание?
  1. В папке config лежит файл с профилями конфигурации параметров Cucumber.
  2. В папке features лежат 1) фича файл smoke.feature, 2) определения степов step_definitions/steps.rb и 3) хуки hooks.rb
  3. В папке lib лежат файлы-хелперы, содержащие реализации методов, которые вызываются в определениях степов.

5.7. Cucumber. Запуск.

Рассмотрим примеры запуска:
1. Будет запущена фича smoke.feature из директории features. Параметр --require указывает, в какой папке (и дочерних подпапках) Cucumber должен искать определения шагов.
Cucumber run example 1 

cucumber --require features features/smoke.feature
2. По-прежнему запускается smoke.feature. Из всей фичи запускается только сценарий с тегом @api.
Cucumber run example 2 

cucumber --require features features/smoke.feature --tags @api
3. Используется отличный от дефолтного профиль.
Cucumber run example 3 

cucumber --require features features/smoke.feature --tags @api --profile WEATHER
10 МАРТА / 2022
Как вам материал?
ПОКАЗАТЬ КОММЕНТАРИИ

Читайте также