Increase reusability of your Steps by using Parameters while rolling out Behavior Driven Development

One of the salient features in any Software Development is Reusability. Without reusability, maintainability and speed of implementation reduces drastically. Same applies when it comes to writing your Features in Behavior Driven Development.

This blog explains, why reusability is important in Behavior Driven Development, how steps can be reused, what are parameters and how they enable reusing steps in your BDD and how reusability can be easily achieved using NoCodeBDD.

Why Reusability is important in Behavior Driven Development?

In order to see why reusability is important, let’s first look at the issues when reusability is not applied when writing Steps in Behavior Driven Development. Let’s look at a Feature with two scenarios and with steps which are not reused

Feature: To check Book API that returns list of books
Scenario 1: Book API should return number of books
When book API is called using the author as “Dan Brown”
Then the response message should return a value of 20

Scenario 2: Book API fails to return all expected books
When book API is called with invalid author as “Invalid Author”
Then the response message should contain a value of 0

In the above two scenarios, if you observe the description of the steps they all vary from each other though they test the same functionality and in this case the behavior that’s been tested is the BOOKS API. As a result, a separate step definition has to be created for each step i.e. in total, 4 step definitions have to be implemented. This is not so much of an issue for a simple scenario like this one, however as the project grows you will end up having hundreds of steps. And by not reusing the steps, you will end up implementing step definitions for all those steps and maintaining them. A change in one of the step definition API structure will result in changing step definitions of all the steps that implements that API. This is not efficient even with a product like NoCodeBDD, where implementing step definitions is as easy as clicking and providing few information.

However the Step description can be changed by using parameters to test different behaviors. Let’s look at how the feature file could be changed so they can be reused

Feature: To check Book API that returns list of books
Scenario 1: Book API should return number of books
When book API is called using the author as “Dan Brown”
Then the response message should return book count as 10

Scenario 2: Book API fails to return all expected books
When book API is called using the author as “invalid author”
Then the response message should return book count as 0

As you can see, by rewriting the step description the steps could be easily reused and at the same time can test different behaviors. With these reused steps, you only have to implement two step definitions.

Reusable Steps in NoCodeBDD

Before we see how implementing reusable steps in NoCodeBDDs are extremely easy to implement, let’s look at what the parameters are.

Parameters

In a Step description all the values that are given within double quotes are considered to be parameters and also all the numbers that are given in a step is considered as a parameter. So in the following steps, “Dan Brown” and 20 are parameters.
When book API is called using the author as “Dan Brown”
Then the response message should contain 20

Implementing Reusable Steps in NoCodeBDD

Once the parameter is defined for one step, wherever the step is reused and passed different values, NoCodeBDD will automatically pass the parameters to the step definition. This is shown in the GIF below:

Making use of reusable steps is one of the main thing to consider while implement Behavior Driven Development and with NoCodeBDD this could be easily achieved. We are on a mission to improve BDD Automation efficiency by 10X. We would love to be part of this journey and provide us any feedback to improve this even further.