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>