Статьи

BDD – Введение и руководство по использованию

Когда меня попросили внедрить TDD / BDD в нашу работу, я много искал одностраничный документ / сайт, но не смог его найти. Хотя есть много очень хороших ресурсов по этой теме, я решил создать одну статью, чтобы продемонстрировать оба эти практических подхода.

обзор

В гибкой разработке организации хотят быть готовыми к выходу на рынок новых продуктов, функций и функциональных возможностей в течение очень короткого периода времени. Но традиционные методики тестирования не могут этого гарантировать. Чтобы не отставать от этой быстрой разработки в Agile-среде, появилось несколько новых методов проектирования для тестирования программного обеспечения. Мы можем назвать несколько таких, как ATDD, TDD, BDD или интеграционное тестирование, но мы ограничимся обсуждением TDD и BDD, которые в настоящее время являются наиболее используемой практикой.

BDD (поведенческая разработка)

Хронологически практика BDD наступает после того, как TDD вступил в действие. По сути, BDD — это эволюция над TDD. Цель этого проекта — создать мост между бизнес-аналитиками и командами разработчиков с помощью общего языка, основанного исключительно на бизнес-требованиях и гибкой практике.

BDD следует процессу, аналогичному TDD, но следует подходу Outside-In, а не TDD. Здесь тестовые случаи пишутся в начале фазы разработки. Чтобы выполнить тест, нужно выполнить тестовый пример, разработчику необходимо написать код бизнес-логики, а затем снова запустить тестовые примеры. То же самое относится и к TDD. Но разница здесь в том, что общий язык используется для описания функциональности. Давайте объясним это гибким способом.

Когда требование к техническим командам приходит к реализации, какой-то бизнес-аналитик / владелец продукта создает функцию в инструменте для совместной работы, таком как Jira или RTC. Теперь каждая функция будет иметь несколько сценариев, которые будут реализованы как критерии приемлемости. Подход BDD принимает критерии приемлемости для реализации в качестве контрольных примеров. Таким образом, пока внедряется новая функция, BDD обеспечивает преобразование всех сценариев в надлежащие тестовые случаи. Таким образом, наибольшим преимуществом подхода BDD является заполнение пробелов между нетехническими командами и командами разработчиков.     

Обзор BDD Framework

В сообществе открытого исходного кода есть пара доступных платформ для практики BDD, например, JBehave, RSpec, GivWenZen и Cucumber. Но мы возьмем Cucumber, поскольку он является наиболее распространенной средой для архитектур Spring Boot и микросервисов.

Огурец

Cucumber — это библиотека с открытым исходным кодом, доступная для большинства языковых платформ, но мы сконцентрируем наше обсуждение только на Java.

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

корнишон

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

Строки в каждом файле Gherkin содержат ключевое слово. Ниже приведены некоторые из наиболее часто используемых ключевых слов:

  • Характерная черта

  • сценарий

  • Дано, Когда, Тогда, И, Но (известный как Шаги)

  • Примеры

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

Функция:  цель ключевого слова Feature — предоставить общее описание функции программного обеспечения. Это должно быть то же описание, что и эпопея или фича в Jira или RTC.

Сценарий:  сценарий дает вам различные ожидаемые результаты для этих конкретных функций. Это может быть несколько случаев успеха / неудачи, как определено в Swagger.

Шаги: каждый шаг начинается с «Дано», «Когда», «Тогда», «И» или «Но». Cucumber выполняет каждый шаг в сценарии по одному в последовательности, в которую вы их записали. Когда Cucumber пытается выполнить шаг, он ищет соответствующее определение шага для выполнения.

  • Дано: вход

  • Когда: метод или функция

  • Затем: ожидаемый результат

  • И: множественный результат

  • Но: если — иначе результат

Конфигурация огурца

Достаточно терминологии и технических деталей. Давайте повеселимся с практическим кодированием. Во-первых, вам нужна любимая IDE (Eclipse, STS или IntelliJ). Мы создадим пример проекта Spring Boot из start.spring.io или воспользуемся плагином и добавим Spring Test Dependency вместе с родительским загрузчиком Starter.

Конфигурация POM

Теперь давайте настроим POM с необходимой зависимостью от Cucumber. Я использовал версию как 2.3.1, но вы также можете использовать последнюю версию.

<properties>
<java.version>1.8</java.version>
<cucumber.version>2.3.1</cucumber.version>
</properties>

<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-integration</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>



<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-java</artifactId>
<version>${cucumber.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-junit</artifactId>
<version>${cucumber.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-spring</artifactId>
<version>${cucumber.version}</version>
<scope>test</scope>
</dependency>
</dependencies>

После того, как вы сконфигурируете POM, давайте запустим сборку Maven, чтобы убедиться, что зависимость введена в вашу локальную систему.

Создать файл объекта

Теперь пришло время написать Огурец в удобочитаемом огуречном файле. По сути, фреймворк Cucumber может читать файл Gherkin, но его нужно назвать  файлом .feature . Итак, мы создали файл ниже в рабочей области Eclipse. Мы назвали как loginAlias.feature .

Класс записи / генерации определений шагов

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

Вы можете скачать плагин с Eclipse MarketPlace

Как только вы установите плагин, вы можете щелкнуть правой кнопкой мыши по файлу объекта и сгенерировать файл StepDefs с помощью плагина (Запуск от имени). В консоли вы можете найти необходимые методы, которые вы можете поместить в StepExecution.class.

Поэтому, если вы видите, что Cucumber Plugin уже разработал необходимые методы для нас в консоли. Итак, нам нужно поместить эти методы в класс Test. Итак, финальный класс Test будет таким, как показано ниже:

Если вы видите пример  StepExecution  класса, вы заметите, что мы дали точные определения в соответствии с Given, When и Then. Единственное, что мы изменили — это шаблон Regex для вставки параметров string и int в методы. В случае несоответствия определений в файле и StepExecution  классе .feature  контрольные примеры не будут пройдены .

Написать класс огурцов

Теперь нам нужно написать класс Cucumber Runner, чтобы класс Runner мог напрямую запускать файлы и StepExecution  класс .feature  .

Итак, класс Runner начинается с того,  @RunWith   что запускает фреймворк Cucumber. Это так же, как  @RunWith   в тестировании JUnit.

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

Бегущий огуречный бегун

Мы все сделали с нашей первичной настройкой, и теперь мы готовы к работе. Нам нужно запустить класс Runner с тестовым примером JUnit. Но, как вы знаете, если нет реальной бизнес-логики, она всегда будет терпеть неудачу, как показано ниже.

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

Пройти тест на огурец

В качестве альтернативы, чтобы пройти тестовый сценарий, мы можем создать сервис SoapUI Mock или написать конечную точку Mock Rest в проекте. Пример может выглядеть следующим образом:

Чтобы пройти тестовый пример, нам нужно расширить этот абстрактный класс в нашем классе StepExecution, и теперь мы можем вызвать конечную точку, созданную  AbstractSpringConfigurationTest  классом. Таким образом, измененный  StepExecution файл класса выглядит следующим образом:

Теперь, если мы запустим класс Runner с JUnit, он должен пройти и показать, как показано ниже:

Надеемся, что с этим объяснением мы сможем вкратце понять основы BDD & Cucumber.