{{announcement.body}}
{{announcement.title}}

BDD – An Introduction and Usage Guide

DZone 's Guide to

BDD – An Introduction and Usage Guide

Take a look at how you can use Cucumber to ensure your BDD methods are up to par.

· DevOps Zone ·
Free Resource

When I was asked to implement TDD/BDD in our work, I searched a lot for a single-page document/site but was not able to find one. Though there are plenty of very good resources available on this topic, I have decided to create a single article to show both of these 2 approaches hands-on.

Overview

In Agile development, organizations want to be market ready for new products, features, and functionalities within a very small period of time. But traditional testing methodologies cannot ensure this. To keep up the pace with this rapid development in an Agile environment, a few new design practices for Software Testing were born. We can name a few like ATDD, TDD, BDD, or Integration Testing, but we will limit our discussion to TDD & BDD which are the most used practice nowadays.

BDD (Behavior-Driven Development)

Chronologically, BDD practice comes after TDD came in action. Basically, BDD is an evolution over TDD. The purpose of this design is to make a bridge between business analyst and development teams through a common language which is purely based on business requirements and Agile practice.

BDD follows a similar process as TDD but it follows an Outside-In approach as opposed to TDD. Here, test cases are written at the start of the development phase. A test case has to be run to fail, the developer needs to write the business logic code, then run the test cases again. The same is true for TDD. But the difference here is the common language used for describing the functionality. Let's explain this in an Agile way.

When a requirement comes to technology teams for implementation, some business analyst/Product Owner creates a feature in a collaborative tool like Jira or RTC. Now every feature will have few scenarios to be implemented which are known as the acceptance criteria. The BDD approach takes the acceptance criteria to be implemented as test cases. So, while a new feature is being implemented, BDD makes sure all the scenarios are converted to proper test cases. Thus, the greatest advantages of the BDD approach is to fill the gaps between non-technical teams and development teams.     


Image title

BDD Framework Overview

There are a couple of available frameworks in the open source community for BDD practice, like JBehave, RSpec, GivWenZen, and Cucumber, to name a few. But we will take Cucumber as it’s the most common framework for Spring Boot and microservices architectures.

Cucumber

Cucumber is an open source library available for most language platforms, but we will concentrate our discussion with only Java.

Before deep dive into Cucumber with examples, we need to understand few basics of it. Basically, Cucumber reads executable specifications written in plain text and validates that the software does what those specifications say. In order for Cucumber to understand the scenarios, they must follow some basic syntax rules, called Gherkin.

Gherkin

Gherkin uses a set of special keywords to give structure and meaning to executable specifications. You can think this as representations of acceptance criteria. Gherkin can be supported by many languages but we will use English as a reference language.

The lines in each Gherkin file contains a keyword. A few of the most used keywords are below:

  • Feature

  • Scenario

  • Given, When, Then, And, But (known as Steps)

  • Examples

There are other few keywords which we will learn on the job itself. A very basic example of Gherkin Structure is below:Image title

Feature: The purpose of the Feature keyword is to provide a high-level description of a software feature. It should be the same description as the epic or feature in Jira or RTC.

Scenario: The scenario gives you the different expected results of that particular features. It can be multiple success/failure cases as defined in Swagger.

Steps: Each step starts with Given, When, Then, And, or But. Cucumber executes each step in a scenario one at a time, in the sequence you’ve written them in. When Cucumber tries to execute a step, it looks for a matching step definition to execute.

  • Given: Input

  • When: Method or Function

  • Then: Expected Result

  • And: Multiple Result

  • But: If – Else Result

Cucumber Configuration

Enough with the terminology and technical details. Let's have some fun with hands-on coding. First, you need a favorite IDE (Eclipse, STS or IntelliJ). We will create a sample Spring Boot project from start.spring.io, or use the plugin and add a Spring Test Dependency along with Starter boot parent.

POM Configuration

Now let's configure the POM with the required Cucumber dependency. I used version as 2.3.1 but you can use the latest version as well.

<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>

Once you configure your POM, let's run a Maven build to ensure the dependency got injected in your local system.

Create Feature File

Now it's time to write the Gherkin in a Cucumber readable file. Basically, the Cucumber framework can read a Gherkin file but that needs to be named as a .feature file. So we have created below file in Eclipse workspace. We named as loginAlias.feature.

Image title

Write/Generate Step Definitions Class

Next step would be to write the test cases which execute the steps defined in the .feature file.Basically, you can write by your own or use a Plugin to generate the StepDefs Java files.

You can download the plugin from Eclipse MarketPlace

Once you install the plugin, you can right click on the feature file and generate the StepDefs file using the Plugin (Run as Feature). In the console, you can find the required methods, which you can put in StepExecution.class.

Image title

So if you see Cucumber Plugin has already developed the required methods for us in the console.So we need to put these methods in a Test class.So the final Test Class will be like below:

Image title

If you see the example StepExecution  class, you will notice we have given the exact definitions as per Given, When, & Then. The only thing we have changed is the Regex pattern to inject the string & int parameters into the methods. If there is any mismatch with the Definitions in .feature file and StepExecution  class, the test cases will not be passed.

Write Cucumber Runner Class

Now we need to write Cucumber Runner class so that Runner class can directly run the .feature files and StepExecution  class.Image title

So the Runner class starts with @RunWith   which starts the Cucumber framework. It is same as @RunWith   in JUnit testing.

 @CucumberOptions  will help us to include the path where all the features are present and it will also give us an option to generate a report of the test cases.

Run Cucumber Runner Class

We are all done with our primary setup and now we are ready to rock. We need to run the Runner Class with JUnit test case. But as you know, if there is no implementation of the actual business logic, it will always fail like below.

Image title

The implementation is not there in the project yet and we are good to implement the business logic. So the next step would be implementing the business logic by the developers.

Pass Cucumber Test Case

Alternately, to pass the test case, we can create SoapUI Mock service or write a Mock Rest Endpoint within the project. The example might look like below:

Image title

To make the test case pass, we need to extend this abstract class in our StepExecution class and we can now call an endpoint created by AbstractSpringConfigurationTest  class. So the modified StepExecution  class file looks like below:

Image title

Now if we run the Runner Class with JUnit, it should pass and show as below:

Image title

Hopefully, with this explanation, we can understand the basics of BDD & Cucumber in a nutshell.

Topics:
tdd ,bdd ,cucumber ,microservices ,testing ,automation

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}