Что такое cucumber framework

Обновлено: 03.07.2024

Заметка с громким названием на достаточно спорную тему - BDD. Многие используют Behavior-Driven Development у себя на проектах, многие его ругают. Но, я уверен, есть люди, которые не видели и не пробовали, как это работает. О том, что такое BDD, в чем его основной смысл, вы можете посмотреть здесь.

Дальше я покажу, как настроить проект, показанный на видео по ссылке выше, с использованием Cucumber, Spring Framework и Selenium. Традиционно пример будет реализован на Java.

Итак начнем. Создаем простой Maven проект и добавляем зависимости в pom.xml:

Далее нам нужно создать класс CucumberRunner, который будет запускать наши сценарии. Сейчас вы удивитесь краткости настроек:

Здесь мы указали формат вывода результатов, формат отчета и путь к папке, где лежат наши feature файлы.

Теги @1 и @2 - это аннотации, с помощью которых мы можем фильтровать сценарии при запуске, указав параметр в CucumberRunner, к примеру tags . Ну вот, с настройкой Cucumber мы справились, теперь приступим к настройке Spring, который будет управлять зависимостями в нашем фреймворке. Создаем в папке src/java/resources файл cucumber.xml:

Теперь приступим к ComponentObject. Создаем класс Page, от которого будем наследовать все наши классы-компоненты.

Создаем класс-компонент Home:

Аннотация @Component говорит Spring о том, что нужно создать инстанс этого класса.

Создаем класс HomeSteps:

Вот она магия Spring - не нужно никаких конструкторов и прочей лишней чепухи, ставим аннотацию @Autowired и все. На этом, собственно, вся настройка заканчивается. Остается создать оставшиеся классы-компоненты, реализовать шаги и запустить тесты. В конце получается красивенький HTML - отчет о результатах прохождения тестов, смотреть его в папке \target\cucumber.html.

Полный код примера вы можете посмотреть в репозитории bitbucket.

Качайте, пробуйте, подписывайтесь на email рассылку, чтобы получать свежие заметки первыми. Спасибо

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

В данной статье мы рассмотрим один из самых популярных фреймворков для автоматизации тестирования с использованием BDD-подхода – Cucumber. Также посмотрим, как он работает и какие средства предоставляет.

Первоначально Cucumber был разработан Ruby-сообществом, но со временем был адаптирован и для других популярных языков программирования. В данной статье рассмотрим работу Cucumber на языке Java.

Gherkin

BDD тесты – это простой текст, на человеческом языке, написанный в форме истории (сценария), описывающей некоторое поведение.

В Cucumber для написания тестов используется Gherkin-нотация, которая определяет структуру теста и набор ключевых слов. Тест записывается в файл с расширением *.feature и может содержать как один, так и более сценариев.

Рассмотрим пример теста на русском языке с использованием Gherkin:


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

Обратите внимание на структуру сценария:

1. Получить начальное состояние системы;
2. Что-то сделать;
3. Получить новое состояние системы.

В примере жирным выделены ключевые слова. Ниже представлен полный список ключевых слов на русском языке:

  1. Дано, Допустим, Пусть – используются для описания предварительного, ранее известного состояния;
  2. Когда, Если – используются для описания ключевых действий;
  3. И, К тому же, Также – используются для описания дополнительных предусловий или действий;
  4. Тогда, То – используются для описания ожидаемого результата выполненного действия;
  5. Но, А – используются для описания дополнительного ожидаемого результата;
  6. Функция, Функционал, Свойство – используется для именования и описания тестируемого функционала. Описание может быть многострочным;
  7. Сценарий – используется для обозначения сценария;
  8. Предыстория, Контекст – используется для описания действий, выполняемых перед каждым сценарием в файле;
  9. Структура сценария, Примеры – используется для создания шаблона сценария и таблицы параметров, передаваемых в него.

Список зарезервированных символов:

Простой проект

Cucumber-проект состоит из двух частей – это текстовые файлы с описанием сценариев (*.feature) и файлы с реализацией шагов на языке программирования (в нашем случае — файлы *.java).

Для создания проекта будем использовать систему автоматизации сборки проектов Apache Maven.
Первым делом добавим cucumber в зависимости Maven:


Для запуска тестов будем использовать JUnit (возможен запуск через TestNG), для этого добавим еще две зависимости:


Библиотека cucumber-junit содержит класс cucumber.api.junit.Cucumber, который позволяет запускать тесты, используя JUnit аннотацию RunWith. Класс, указанный в этой аннотации, определяет каким образом запускать тесты.

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


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

Рассмотрим опции Cucumber:

  1. features – путь к папке с .feature файлами. Фреймворк будет искать файлы в этой и во всех дочерних папках. Можно указать несколько папок, например: features = ;
  2. glue – пакет, в котором находятся классы с реализацией шагов и «хуков». Можно указать несколько пакетов, например, так: glue = ;
  3. tags – фильтр запускаемых тестов по тэгам. Список тэгов можно перечислить через запятую. Символ

исключает тест из списка запускаемых тестов, например

Создание «фичи»

В папке src/test/features создадим файл с описание тестируемого функционала. Опишем два простых сценария снятия денег со счета — успешный и провальный.

Попробуем запустить RunnerTest со следующими настройками:


В консоль появился результат прохождения теста:


Cucumber не нашел реализацию шагов и предложил свои шаблоны для разработки.
Создадим класс MyStepdefs в пакете ru.savkk.test и перенесем в него методы, предложенные фреймворком:


При запуске теста Cucumber проходит по сценарию шаг за шагом. Взяв шаг, он отделяет ключевое слово от описания шага и пытается найти в Java-классах пакета указанного в опции glue аннотацию с регулярным выражением, подходящим описанию. Найдя совпадение, фреймворк вызывает метод с найденной аннотацией. Если несколько регулярных выражений удовлетворяют описанию шага, фреймворк выбрасывает ошибку.

Как было сказано выше, для Cucumber технически нет отличия в ключевых словах, описывающих шаги, это верно и для аннотации, например:


для фреймворка являются одинаковыми.

То, что в регулярных выражениях записано в скобках передается в метод в виде аргумента. Фреймворк самостоятельно определяет, что необходимо передавать из сценария в метод в виде аргумента. Это числа — (\\d+). И текст, экранированный в кавычки — \"([^\"]*)\". Это самые распространённые из передаваемых аргументов.

Ниже в таблице представлены элементы, используемые в регулярных выражениях:
регулярных выражениях:

Передача коллекций в аргументы

Часто возникает ситуация, когда из сценария в метод необходимо передать набор однотипных данных – коллекций. Для подобной задачи в Cucumber есть несколько решений:

    Фреймворк по умолчанию оборачивает данные, перечисленные через запятую, в ArrayList:

Для замены разделителя, можно воспользоваться аннотацией Delimiter:

DataTable – это класс, который эмулирует табличное представление данных. Для доступа к данным в нем имеется большое количество методов. Рассмотрим некоторые из них:


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

Данный пример выведет на консоль:

Файл
Редактировать
О программе


Метод преобразует таблицу в список списков:

На консоль будет выведено:

Файл true 5
Редактировать false 8


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

Метод выведет на консоль:

Редактировать false 8
О программе true 2

Создадим для примера класс Menu:


Для первого способа шаг в сценарии запишем в следующем виде:


Вывод в консоль:

Файл true 5
Редактировать false 8
О программе true 2

Фреймворк создает связанный список объектов из таблицы с тремя колонками. В первой строке таблицы должны быть указаны наименования полей класса, создаваемого объекта. Если какое-то поле не указать, оно не будет инициализировано.

Для второго способа приведем шаг сценария к следующему виду:


А в аргументе описания шага используем аннотацию @Transpose.


Cucumber, как и в предыдущем примере, создаст связанный список объектов, но, в данном случае, наименования полей записывается в первой колонке таблицы.

Для передачи многострочных данных в аргумент метода, их необходимо экранировать тремя двойными кавычками:


Данные в метод приходят в виде объекта класса String:

Фреймворк самостоятельно приводит данные из сценария к типу данных, указанному в аргументе метода. Если это невозможно, то выбрасывает исключение ConversionException. Это справедливо и для классов Date и Calendar. Рассмотрим пример:

Все прекрасно сработало, Cucumber преобразовал 04.05.2017 в объект класса Date со значением «Thu May 04 00:00:00 EET 2017».

Рассмотрим еще один пример:

Дойдя до этого шага, Cucumber выбросил исключение:


Почему первый пример сработал, а второй нет?

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

Структура сценария

Бывают случаи, когда необходимо запустить тест несколько раз с различным набором данных, в таких случая на помощь приходит конструкция «Структура сценария»:


Суть данной конструкции заключается в том, что в места, обозначенные символами <>, вставляются данные из таблицы Примеры. Тест будет запускаться поочередно для каждой строки из данной таблицы. Названия колонок должно совпадать с названием мест вставки данных.

Использование хуков

Cucumber поддерживает хуки (hooks) – методы, запускаемые до или после сценария. Для их обозначения используется аннотация Before и After. Класс с хуками должен находиться в пакете, указанном в опциях фреймворка. Пример класса с хуками:


Метод c аннотацией Before будет запускаться перед каждым сценарием, After – после.

Порядок выполнения

Хукам можно задать порядок, в котором они будут выполняться. Для этого необходимо в аннотации указать параметр order. По умолчанию значение order равно 10000.

Для Before чем меньше это значение, тем раньше выполнится метод:


В данном примере первым выполнится метод connectToServer(), затем prepareData().

After отрабатывает в обратном порядке.

Тэгирование


В параметре value можно указать тэги сценариев, для которых будут отрабатывать хуки. Символ

означает «за исключением». Пример:


Метод connectToServer будет выполнен для всех сценариев с тэгом correct, метод prepareData для всех сценариев за исключением сценариев с тэгом fail.

Scenario class

Если в определении метода-хука в аргументе указать объект класса Scenario, то в данном методе можно будет узнать много полезной информации о запущенном сценарии, например:


Выведет в консоль:

аутентификация-банковской-карты;успешная-аутентификация
Успешная аутентификация
passed
false
[@correct, @all]







Что пишут в блогах

Подписаться

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты


Автор: Сурин Анатолий, ведущий инженер по тестированию АО «СберТех»

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

В данной статье мы рассмотрим один из самых популярных фреймворков для автоматизации тестирования с использованием BDD-подхода – Cucumber. Также посмотрим, как он работает и какие средства предоставляет.

Первоначально Cucumber был разработан Ruby-сообществом, но со временем был адаптирован и для других популярных языков программирования. В данной статье рассмотрим работу Cucumber на языке Java.

Gherkin

BDD тесты – это простой текст, на человеческом языке, написанный в форме истории (сценария), описывающей некоторое поведение.

В Cucumber для написания тестов используется Gherkin-нотация, которая определяет структуру теста и набор ключевых слов. Тест записывается в файл с расширением *.feature и может содержать как один, так и более сценариев.

Рассмотрим пример теста на русском языке с использованием Gherkin:


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

Обратите внимание на структуру сценария:

1. Получить начальное состояние системы;
2. Что-то сделать;
3. Получить новое состояние системы.

В примере жирным выделены ключевые слова. Ниже представлен полный список ключевых слов на русском языке:

  1. Дано, Допустим, Пусть – используются для описания предварительного, ранее известного состояния;
  2. Когда, Если – используются для описания ключевых действий;
  3. И, К тому же, Также – используются для описания дополнительных предусловий или действий;
  4. Тогда, То – используются для описания ожидаемого результата выполненного действия;
  5. Но, А – используются для описания дополнительного ожидаемого результата;
  6. Функция, Функционал, Свойство – используется для именования и описания тестируемого функционала. Описание может быть многострочным;
  7. Сценарий – используется для обозначения сценария;
  8. Предыстория, Контекст – используется для описания действий, выполняемых перед каждым сценарием в файле;
  9. Структура сценария, Примеры – используется для создания шаблона сценария и таблицы параметров, передаваемых в него.

Ключевые слова, перечисленные в пунктах 1-5, используются для описания шагов сценария, Cucumber их технически не различает. Вместо них можно использовать символ *, но делать так не рекомендуется. У этих слов есть определенная цель, и они были выбраны именно для неё.

Список зарезервированных символов:

Простой проект

Cucumber-проект состоит из двух частей – это текстовые файлы с описанием сценариев (*.feature) и файлы с реализацией шагов на языке программирования (в нашем случае — файлы *.java).

Для создания проекта будем использовать систему автоматизации сборки проектов Apache Maven.
Первым делом добавим cucumber в зависимости Maven:


Для запуска тестов будем использовать JUnit (возможен запуск через TestNG), для этого добавим еще две зависимости:


Библиотека cucumber-junit содержит класс cucumber.api.junit.Cucumber, который позволяет запускать тесты, используя JUnit аннотацию RunWith. Класс, указанный в этой аннотации, определяет каким образом запускать тесты.

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


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

Рассмотрим опции Cucumber:

  1. features – путь к папке с .feature файлами. Фреймворк будет искать файлы в этой и во всех дочерних папках. Можно указать несколько папок, например: features = ;
  2. glue – пакет, в котором находятся классы с реализацией шагов и «хуков». Можно указать несколько пакетов, например, так: glue = ;
  3. tags – фильтр запускаемых тестов по тэгам. Список тэгов можно перечислить через запятую. Символ

исключает тест из списка запускаемых тестов, например


Для фильтрации запускаемых тестов нельзя одновременно использовать опции tags и name.

Создание «фичи»

В папке src/test/features создадим файл с описание тестируемого функционала. Опишем два простых сценария снятия денег со счета — успешный и провальный.

Попробуем запустить RunnerTest со следующими настройками:


В консоль появился результат прохождения теста:


Cucumber не нашел реализацию шагов и предложил свои шаблоны для разработки.
Создадим класс MyStepdefs в пакете ru.savkk.test и перенесем в него методы, предложенные фреймворком:


При запуске теста Cucumber проходит по сценарию шаг за шагом. Взяв шаг, он отделяет ключевое слово от описания шага и пытается найти в Java-классах пакета указанного в опции glue аннотацию с регулярным выражением, подходящим описанию. Найдя совпадение, фреймворк вызывает метод с найденной аннотацией. Если несколько регулярных выражений удовлетворяют описанию шага, фреймворк выбрасывает ошибку.

Как было сказано выше, для Cucumber технически нет отличия в ключевых словах, описывающих шаги, это верно и для аннотации, например:


для фреймворка являются одинаковыми.

То, что в регулярных выражениях записано в скобках передается в метод в виде аргумента. Фреймворк самостоятельно определяет, что необходимо передавать из сценария в метод в виде аргумента. Это числа — (\\d+). И текст, экранированный в кавычки — \"([^\"]*)\". Это самые распространённые из передаваемых аргументов.

Ниже в таблице представлены элементы, используемые в регулярных выражениях:
регулярных выражениях:

Передача коллекций в аргументы

Часто возникает ситуация, когда из сценария в метод необходимо передать набор однотипных данных – коллекций. Для подобной задачи в Cucumber есть несколько решений:

    Фреймворк по умолчанию оборачивает данные, перечисленные через запятую, в ArrayList:

Для замены разделителя, можно воспользоваться аннотацией Delimiter:

DataTable – это класс, который эмулирует табличное представление данных. Для доступа к данным в нем имеется большое количество методов. Рассмотрим некоторые из них:


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

Данный пример выведет на консоль:

Файл
Редактировать
О программе


Метод преобразует таблицу в список списков:

На консоль будет выведено:

Файл true 5
Редактировать false 8


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

Метод выведет на консоль:

Редактировать false 8
О программе true 2

Создадим для примера класс Menu:


Для первого способа шаг в сценарии запишем в следующем виде:


Вывод в консоль:

Файл true 5
Редактировать false 8
О программе true 2

Фреймворк создает связанный список объектов из таблицы с тремя колонками. В первой строке таблицы должны быть указаны наименования полей класса, создаваемого объекта. Если какое-то поле не указать, оно не будет инициализировано.

Для второго способа приведем шаг сценария к следующему виду:


А в аргументе описания шага используем аннотацию @Transpose.


Cucumber, как и в предыдущем примере, создаст связанный список объектов, но, в данном случае, наименования полей записывается в первой колонке таблицы.

Для передачи многострочных данных в аргумент метода, их необходимо экранировать тремя двойными кавычками:


Данные в метод приходят в виде объекта класса String:

Фреймворк самостоятельно приводит данные из сценария к типу данных, указанному в аргументе метода. Если это невозможно, то выбрасывает исключение ConversionException. Это справедливо и для классов Date и Calendar. Рассмотрим пример:


Все прекрасно сработало, Cucumber преобразовал 04.05.2017 в объект класса Date со значением «Thu May 04 00:00:00 EET 2017».

Рассмотрим еще один пример:


Дойдя до этого шага, Cucumber выбросил исключение:


Почему первый пример сработал, а второй нет?

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

Структура сценария


Бывают случаи, когда необходимо запустить тест несколько раз с различным набором данных, в таких случая на помощь приходит конструкция «Структура сценария»:


Суть данной конструкции заключается в том, что в места, обозначенные символами <>, вставляются данные из таблицы Примеры. Тест будет запускаться поочередно для каждой строки из данной таблицы. Названия колонок должно совпадать с названием мест вставки данных.

Использование хуков

Cucumber поддерживает хуки (hooks) – методы, запускаемые до или после сценария. Для их обозначения используется аннотация Before и After. Класс с хуками должен находиться в пакете, указанном в опциях фреймворка. Пример класса с хуками:


Метод c аннотацией Before будет запускаться перед каждым сценарием, After – после.

Порядок выполнения

Хукам можно задать порядок, в котором они будут выполняться. Для этого необходимо в аннотации указать параметр order. По умолчанию значение order равно 10000.

Для Before чем меньше это значение, тем раньше выполнится метод:


В данном примере первым выполнится метод connectToServer(), затем prepareData().

After отрабатывает в обратном порядке.

Тэгирование

В параметре value можно указать тэги сценариев, для которых будут отрабатывать хуки. Символ

означает «за исключением». Пример:


Метод connectToServer будет выполнен для всех сценариев с тэгом correct, метод prepareData для всех сценариев за исключением сценариев с тэгом fail.

Scenario class

Если в определении метода-хука в аргументе указать объект класса Scenario, то в данном методе можно будет узнать много полезной информации о запущенном сценарии, например:


Выведет в консоль:

аутентификация-банковской-карты;успешная-аутентификация
Успешная аутентификация
passed
false
[@correct, @all]

Cucumber - это среда автоматического тестирования, которая поддерживает BDD (Behavior Driven Development), то есть разработку, управляемую поведением. Перед модульным тестированием или интеграционным тестированием этапы тестирования и информация о проверке заранее определяются на общем языке (английском), чтобы не разработчики могли понять этапы тестирования, цель каждого этапа модульного тестирования и интеграционного тестирования. А те, кто пишет модульные тесты и интеграционные тесты, могут писать код на основе заранее написанного фреймворка для достижения цели разработки, основанной на поведении.

1. Импортируйте плагин Cucumber в eclipse.Метод импорта такой же, как и у других плагинов здесь, поэтому нет никаких объяснений.

2. Создайте новый проект Java и импортируйте пакет jar, требуемый Cucumber, в проект Java (лучше создать новую папку и поместить в эту папку пакет jar).



3. Добавьте недавно импортированные файлы JAR через Путь сборки.





4. Создайте новый файл формата объекта, используемый для определения шагов. Вновь созданный файл формата объекта автоматически заполнит файл шаблона. Конкретный метод использования будет описан позже. Как и выше, лучше всего поместить его в определенную папку, в этом примере - папка Feature.





5. Импортируйте протестированный пакет в проект Java. В этом примере тестируется простой класс Calculator.


6. Создайте новый пакет.Имя пакета должно быть test.java или main.java, иначе при последующих этапах создания шагов определения Cucumber возникнет ошибка.

7. Создайте новый класс Step-Definition в пакете test.java.





1. .feature файл

Определяет шаги теста, включая следующие ключевые слова

  • Feature :Один .feature В файле есть ровно одно ключевое слово Feature. Опишите объект для тестирования, обычно это название теста.
  • Scenario :Один .feature В файле может быть 0 или более ключевых слов сценария. Сценарий тестового объекта, например тестовый метод Add (), может иметь несколько сценариев, таких как добавление двух целых чисел и добавление двух отрицательных чисел.
  • Given :Один .feature В файле есть ровно одно ключевое слово Given. Это эквивалентно заданным условиям в тестовом примере. Если вы хотите выразить несколько предустановленных условий, вы можете добавить их с помощью ключевого слова And.
  • When :Один .feature В файле есть ровно одно ключевое слово When. Конкретные шаги операции аналогичны шагам в тестовом примере. Если вы хотите выразить несколько этапов операции, вы можете добавить их с помощью ключевого слова And.
  • Then :Один .feature В файле есть ровно одно ключевое слово Then. Это эквивалентно ожидаемому результату в тестовом примере. Если вы хотите выразить несколько ожидаемых результатов, вы можете добавить их с помощью ключевого слова And.
  • And :Один .feature В файле может быть ноль или более ключевых слов And. Элемент And может дополнять дополнительные предустановленные условия или рабочие шаги.
  • But :Один .feature В файле может быть ноль или более ключевых слов But. Но, как и And, может использоваться вместе с Given, When и Then для добавления описаний отрицательных типов, обычно применимых только к отрицательным условиям. Такие как:

BUT home page should not be missing

  • Scenario Outline :Один .feature В файле может быть ноль или более ключевых слов схемы сценария. Когда в сцене есть несколько наборов значений, они должны использоваться вместе с примером и появляться парами.
  • Examples : Отображается в паре со схемой сценария, под которой находится список из нескольких тестовых значений.


2. Step-definition файл

Определение шага Cucumber в основном такое же, как и в других файлах формата Java, но вы можете выборочно проверять и автоматически добавлять комментарии Give, When, Then, And, But при создании.


После завершения будет автоматически сгенерирован файл java-шаблона, включающий ранее отмеченные комментарии.В этом примере отмечены флажками Given, When, Then и And. Формат комментария:

@Given("^you are in Given annotation$")

Содержимое в скобках после ключевого слова должно соответствовать содержимому ключевого слова в ранее определенном файле .feature. Распознавание регистра и количество пробелов должны быть одинаковыми. ^ Начинается, $ заканчивается. После того, как комментарий - это метод, который будет реализован, добавьте код, соответствующий операции, описанной после ключевого слова в методе.

3. Файл выполнения теста

Файл выполнения теста Cucumber, как правило, представляет собой пустой тестовый пример Junit, то есть без комментариев к тесту и без комментариев, таких как до и после. Когда необходимо добавить аннотацию RunWith и CucumberOptions.

Аннотации RunWith одинаковы для каждого тестового файла фреймворка Cucumber, так как RunWith(Cucumber.class) 。 Содержимое аннотации CucumberOption необходимо изменить вручную в соответствии с реальной ситуацией.

Параметры аннотации CucumberOptions обычно имеют features 、 glue 、 monochrome с участием dryrun Подождите. среди них. f eature s с участием glue Необходимо, m onochrome с участием dryrun По желанию.

Features определяет относительный путь к файлу .feature в формате features = "имя файла .feature в папке проекта / .feature файл". например, features = "Feature / CalculatorAdd.feature"

Glue определяет имя пакета Step-difinition в формате glue = "полное имя пакета". например test.java.cucumberDefinition.

Параметр «монохромный» имеет два значения: «истина» и «ложь», значение по умолчанию - ложь, а формат - монохромный = логический. Используется для контроля удобочитаемости результатов тестирования. Если монохромный = true, результаты теста более читабельны. Когда монохромный = true, читаемость результатов теста плохая.

Параметр «сухой прогон» временно неизвестен.

Благодаря введению, приведенному выше, в основном создается фреймворк Cucumber, и также понимается роль файлов Cucumber.Следующим шагом является реализация простого модульного теста в режиме BDD путем изменения фреймворка.

В этом учебнике дается введение в Cucumber , широко используемый инструмент для приемочного тестирования пользователей, и как использовать его в тестах REST API.

Кроме того, чтобы сделать статью самодостаточной и независимой от каких-либо внешних служб REST, мы будем использовать WireMock, библиотеку веб-сервисов, использующих stubbing и mocking. Если вы хотите узнать больше об этой библиотеке, пожалуйста, обратитесь к введению в WireMock .

2. Корнишон – Язык огурца

Cucumber-это платформа тестирования , которая поддерживает Behavior Driven Development (BDD) , позволяя пользователям определять операции приложения в виде обычного текста. Он работает на основе Gherkin Domain Specific Language (DSL). Этот простой, но мощный синтаксис корнишона позволяет разработчикам и тестировщикам писать сложные тесты, сохраняя его понятным даже для нетехнических пользователей.

2.1. Введение в корнишон

Вся структура должна быть записана в файл с расширением feature , который будет распознан Cucumber.

Вот простой пример документа из корнишона:

В следующих разделах мы опишем несколько наиболее важных элементов в структуре корнишонов.

2.2. Характеристика

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

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

2.3. Сценарии и шаги

Эти действия выполняются с помощью шагов, определенных одним из пяти ключевых слов: Дано , Когда , Тогда , И , и Но|/.

  • Данный : Этот шаг должен привести систему в четко определенное состояние, прежде чем пользователи начнут взаимодействовать с приложением. Предложение Given можно считать предварительным условием для варианта использования.
  • When : Шаг When используется для описания события, которое происходит с приложением. Это может быть действие, предпринятое пользователями, или событие, вызванное другой системой.
  • Затем : Этот шаг предназначен для указания ожидаемого результата теста. Результат должен быть связан с бизнес-ценностями тестируемой функции.
  • И и Но : Эти ключевые слова можно использовать для замены приведенных выше ключевых слов шага, когда существует несколько шагов одного и того же типа.

Огурец на самом деле не различает эти ключевые слова, однако они все еще существуют, чтобы сделать функцию более читаемой и согласованной со структурой BDD.

3. Реализация Cucumber-JVM

Cucumber изначально был написан на Ruby и был портирован на Java с реализацией Cucumber-JVM, которая является предметом этого раздела.

3.1. Зависимости Maven

Чтобы использовать Cucumber-JVM в проекте Maven, в POM необходимо включить следующую зависимость:

Чтобы облегчить тестирование JUnit с огурцом, нам нужно иметь еще одну зависимость:

В качестве альтернативы мы можем использовать другой артефакт, чтобы воспользоваться преимуществами лямбда-выражений в Java 8, которые не будут рассмотрены в этом руководстве.

3.2. Определения шагов

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

Чтобы сделать это более ясным, давайте рассмотрим следующий шаг:

И определение шага:

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

4. Создание и запуск тестов

4.1. Написание файла функций

Давайте начнем с объявления сценариев и шагов в файле с именем, заканчивающимся расширением .feature :

Теперь мы сохраняем этот файл в каталоге с именем Feature при условии , что каталог будет загружен в путь к классу во время выполнения, например src/main/resources .

4.2. Настройка JUnit для работы с Огурцом

Для того, чтобы JUnit знал о Cucumber и читал файлы функций при запуске, класс Cucumber должен быть объявлен как Runner . Нам также нужно указать JUnit место для поиска файлов функций и определений шагов.

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

4.3. Написание определений шагов

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

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

Ниже приведен метод, который полностью соответствует шагу корнишона. Этот метод будет использоваться для отправки данных в веб-службу REST:

А вот метод, соответствующий шагу корнишона и принимающий аргумент из текста, который будет использоваться для получения информации из веб-службы REST:

Как вы можете видеть, пользователи Получают информацию О проекте метод принимает аргумент String , который является именем проекта. Этот аргумент объявлен в аннотации, и здесь он соответствует Cucumber в тексте шага.

В качестве альтернативы мы могли бы использовать регулярное выражение:

Мы предоставим рабочий код для обоих вышеперечисленных методов в следующем разделе.

4.4. Создание и выполнение тестов

Во-первых, мы начнем со структуры JSON, чтобы проиллюстрировать данные, загруженные на сервер по запросу POST и загруженные клиенту с помощью GET. Эта структура сохраняется в поле json String и показана ниже:

Для демонстрации REST API мы используем сервер WireMock:

Теперь давайте перейдем к написанию тестового кода в рамках определений шагов. Мы сделаем это для того, чтобы пользователи сначала Загружали Данные По Проекту методу.

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

Использование API WireMock для заглушения службы REST:

Теперь отправьте запрос POST с содержимым, взятым из поля json String , объявленного выше, на сервер:

Следующий код утверждает, что запрос POST был успешно получен и обработан:

Сервер должен остановиться после использования:

Отправка запроса GET и получение ответа:

Вот реализация этого вспомогательного метода преобразования:

Следующее проверяет весь процесс:

Наконец, остановите сервер, как описано ранее.

5. Параллельное выполнение функций

Cucumber-JVM изначально поддерживает параллельное выполнение тестов в нескольких потоках. Мы будем использовать JUnit вместе с плагином Maven Failsafe для выполнения бегунов. В качестве альтернативы мы могли бы использовать Maven Surefire.

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

Теперь давайте добавим конфигурацию плагина:

Обратите внимание, что:

  • параллельный: может быть классами, методами или и тем , и другим – в нашем случае классы заставят каждый тестовый класс запускаться в отдельном потоке
  • количество потоков: указывает, сколько потоков должно быть выделено для этого выполнения

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

6. Заключение

В этом уроке мы рассмотрели основы Cucumber и то, как этот фреймворк использует доменный язык Gherkin для тестирования REST API.

Как обычно, все примеры кода, показанные в этом руководстве, доступны на GitHub .

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