Behavior Driven Development with Gherkin | The Complete Guide for BDD Testing

How can we bridge the gap between business and development? How do we make sure that features being developed are according to the business requirements from the beginning? The answer is Behavior Driven Development (BDD), a framework that allows the business requirements to be converted into test cases that are reviewable by business and users when needed.

Let us start with understanding what Behavior Driven Development and the purpose it serves in detail below is.

Behavior Driven Development (BDD)

BDD came to the fore when the test automation was proving too technical for non-technical team members and stakeholders. To improve the situation, a layer was introduced to add easy-to-understand English while the code would be at the backend.

But now there is a tool that lets you skip the backend coding and create an easy to understand frontend, which also can be executed automated test run. Testsigma provides this interface. To help you understand the differences and similarities between Cucumber, a well-known BDD tool and Testsigma, here is a comparison document too: [Cucumber vs Testsigma]

What is meant by Behavior Driven Development (BDD)?

BDD is a software development process driven by an application’s behavior and is sometimes called an extension of the Test Driven Development (TDD) approach.

What are the Principles of Behavior Driven Development?

Have ample time for everything: Planning, development, and testing should all be given adequate time.

Withholding value while maintaining quality: Shooting in the dark is counterproductive since it impedes clients, stakeholders, and users. As a result, proper requirements analysis gets a thumbs up, and BDD follows.

Behavior in a nutshell: Concentrate more on the product’s behavior, resulting in better delivery and happier customers.

Let us have an idea about TDD, to understand BDD properly.

What is Test Driven Development(TDD)?

TDD, as the name implies, is driven by tests. Here, a developer is required to write tests corresponding to each small functionality before developing them. Once the development is completed, the test case corresponding to the implemented functionality should pass. Then the code can be refactored to improve its quality.

Below figure from depicts the process followed by TDD.

What is the Difference Between BDD and TDD?

• TDD approach helps make an application stable. However, it isn’t easy to understand the automated tests for non-technical team members and other stakeholders. To address this issue, BDD came into the picture.
• In BDD, to start with, the test cases are first defined on the frontend in a human-friendly language, mostly ‘Gherkin’. Once the feature is developed, the test cases are automated in some programming language. The implementation is kept in the backend, mapping each step to the frontend. The easy-to-understand frontend for a test case in BDD makes an automated test case easy to review for managers and other stakeholders for a project. The test cases are defined to replicate the system’s behavior, thus the name ‘Behavior Driven Development’.Thus, whereas TDD begins with a focus on developing unit tests by developers, BDD starts with specifying the system’s behavior in a human-friendly format.
• The BDD approach gives clear visibility about the implemented business use cases as the frontend is in plain English. This frontend can be quickly reviewed by anyone in the entire team, including QA team, Dev team, Business Analyst, sales team and other stakeholders. In contrast, in the TDD approach, automated test cases are tough to review as developers define them in the programming language used for development.

BDD Process

Below figure shows the process followed by Behaviour Driven Development:

Prerequisites for Implementing BDD

Some essentials, as mentioned below, need to be in place before implementing BDD approach:-

1. All requirements should be created as a story, and each user story should be very well defined with concrete examples.

2. Every example in a user story must be a valid scenario explaining the user’s viewpoint and not just a test case.

3. Sound understanding of BDD framework/process and the tool used.

4. Hands on with one of the programming languages (like JAVA (preferred), Python, Ruby, C#) that will be needed to automate a test case in the backend.

How Behavior Driven Development Works?

Behavior-driven development (BDD) is an agile way of making software that focuses on what the software should do rather than how it should be made. It involves everyone involved in the project – developers, testers, and business analysts – working together to ensure the software meets all requirements. The main idea behind BDD is that the software should be created with customer needs and business value in mind.

Here are the key points on how BDD works:

1. Collaboration: BDD is a way of working involving everyone involved in building software to make sure it meets the needs and expectations of all parties.
2. Requirements as behavior: BDD is all about ensuring the software does what it’s supposed to do for the people who use it. Instead of just writing down technical details, BDD focuses on capturing the behaviors that the software should have to meet users’ needs.
3. Automated testing: BDD uses automated testing to ensure the software does what it should. The tests are written in a way that everyone involved, even people who don’t know much about technology, can understand.
4. Continuous delivery: BDD helps ensure the software you’re building meets people’s wants, so you can get feedback and keep improving it quickly.

Benefits of Using BDD

Here are some of the key advantages of implementing BDD: 

1. In BDD, you are not defining ‘test’, but defining the ‘behaviour’ of the system in plain language to directly trace the business objectives which also helps in involving non-technical team members for reviews.

2. Improves communication among the team members like developers, testers, product owners and other stakeholders.

3. Having clear behaviour visibility results in quality code which reduces the cost of maintenance and eliminates the risk.

4. Since BDD front-end is non-technical in nature and uses natural language to explain the behaviour it helps in ensuring correctness of implementation from an early stage.

5. Acceptance criteria are already converted to user stories/test scenarios before the actual development in Behavioral Driven approach. Thus, automation testers can start with testing processes even before the product is ready for testing.

Demerits of Using Behavior Driven Development

There are some disadvantages as well as using BDD. Here are some mentioned below:

1. BDD is incompatible with the waterfall approach.

2. BDD is ineffective without a proper definition of business requirements since it does not cope well with poorly written user stories.

3. Sufficient technical and programming skills are required for testers as well.

Behavior Driven Development Tools

There are several open-source and paid tools available for BDD framework. Here are some of the common examples below.

1) Cucumber Studio  

2) Cucumber

3) JBehave

4) SpecFlow

5) Jdave

6) Instinct

7) Specs

Behavior Driven Development Tool Selection

In order to implement BDD framework any one of the tools mentioned above can be selected based on the below factors: 

1. The programming language being used in the source code of the product/project.

2. Nature of the Project. 

3. Team competency, team discussions and other software requirements. 

Approved budget in case of choosing a licensed tool. 

However, among all of the above BDD tools, Cucumber is the most common and widely used tool. Cucumber was written in Ruby programming language and used for Ruby testing initially. However, cucumber is now supported by other programming languages also like JAVA, .Net.

For writing specifications or business behaviour in the frontend for BDD Frameworks, Gherkin is the most widely used language

What is Gherkin?

Gherkin is a domain-specific language that enables the definition of business behaviour without the need for implementation. Since Gherkin uses plain English language to define the test, it is very easy for technical and non-technical team members to understand the test or behaviour of the software.

Writing Gherkin Test:

Some keywords are used in Gherkin to define complete tests, including pre-condition, test description, expected outcome etc.

Here are some of the common keywords used in gherkin language:

1. Feature.

2. Scenario outline.

3. Given, When, Then, And, (Steps)

4. Background.

5. Scenario

6. Rule

7. Example

Each keyword has its meaning used in writing a great Gherkin test. Those Keywords are explained below to have an understanding of each one of them.

Feature

Each Gherkin file starts with a keyword Feature, followed by a definition of the logical test functionality to be tested on that feature file. In other words, the feature describes what the application is supposed to do. Feature keyword is also used to group multiple scenarios.

This isn’t only for testing purposes but also allows you to add documentation on requirements and business rules. Feature keyword is found at the start of a feature file.

The description section ends when we start a new line with the other keywords, such as scenario outline, example, rule background etc.

Descriptions

When required, free-form descriptions could be written underneath the given keywords, as long as all the lines are being written without any keyword.

Rule

The purpose of the rule keyword is to represent one business rule that needs to be incorporated. This keyword provides additional context for a feature. These “rules” can have one or more scenarios that can belong to the business rule and may also have a background section.

Gherkin Steps

Some gherkin steps specific keywords are used in the Gherkin test. These are:

1. Given
2. When
3. Then
4. And
5. But

Now, let’s understand the use for each one of them below:

1. Given:

Given step is used to describe the initial information of the system. Usually, it describes the prerequisites before a test case execution can start.

When cucumber runs a Given step, it configures the system to be in an already defined state, such as object configuration or adding required data to a test database.

The objective of Given step is to have the system in a known state before the user starts interacting with the When steps. It is good not to talk about user interaction in Given steps.

Given steps are the preconditions if you are creating the use cases. It is also valid and okay to have several Given steps if required.

Few examples:

• Mike and Jack have started the game
• User is logged in
• User has a balance of $40

2. When

Step written under When a keyword describes an event and an action. This can be a person or user interacting with the software/system. Also, it could be an event triggered by another or an external system.

It’s highly recommended that you have a single When step for one Scenario. If multiple when are needed, then splitting that kind of scenario into multiple scenarios is advised.

Examples:

• Click login button
• Invite a connection
• Withdraw money
• Declare a nominee

3. Then

Step written under ‘Then’ keyword is used to describe an expected result or an outcome.

The step definition of a Then step uses an assertion to match the actual outcome (Actual outcome of the When step) to the expected outcome about what the system is supposed to do.

The outcome of this step should be an observable output that is something like a report, message or user interface and not an internal behaviour of the system like a record inside a database.

Examples:

• See that the login was successful
• The nominee is declared or added
• Connection is invited

4. And, But

When we have multiple steps for the one type of step like, for eg. 2 conditions that should be valid as a prerequisite, then after ‘Given’ the two steps can be separated by an ‘And’. Similarly, for ‘But’. These can be used with ‘Given’,’ When’ or ‘Then’ as needed. Using these keywords helps keep the documentation organized and increases readability by making it more structured.

Background

Sometimes you may find that you are repeating the same Given steps in all of the scenarios in the feature.

Since they are repeated in each scenario, this is a sign that those steps are not essential to describe the scenarios. They are just the event details. We can move such Given steps to the background by grouping them all under a Background section.

A Background enables you to add even more context to the scenarios in the feature. Background can also contain one or multiple Given steps.

A Background is executed before every scenario and after any Before hooks. We must put the Background before the first Scenario in the feature file.

We can only have a single set of Background steps for one feature. If you want different Background steps for each scenario, you must split them into different feature files.

Scenario Outline

The keyword Scenario Outline executes the same scenario multiple times with different values.

For eg, without scenario outline, passing multiple values to the same scenario as different cases increase the time and effort required in test case creation and execution, as can also be seen below:

1. Scenario: eat 6 out of 15

Given there are a total of 15 bananas

When I eat 6 Bananas

Then I will have 9 bananas

2. Scenario: eat 8 out of 20

Given there are a total of 20 bananas

When I eat 8 bananas

Then I will have 12 bananas

Above kind of scenarios can be described more concisely through Scenario Outline using <> tags.

For example:

Scenario Outline: Eating Bananas

Given there are <Total> Bananas

When I eat <eaten> Bananas

Then I should have <leftover> Bananas

Examples:

As discussed in this article, in a BDD framework, there is a frontend file that uses Gherkin syntax, and a backend file that is implemented using a programming language. In Cucumber, the frontend file is called a feature, and the backend file is called step definition.

In the step definition file, implementation corresponds to all the outlined steps in the feature file, and the mapping is ensured. Read more about step definitions here.

During execution, before trying to match a step against the respective step definition, Cucumber would replace the parameters with values from the table.

Overall Feature File Example:

Eventually, we can say a feature file is the core specification or behaviour of the system against the step definition. Below is a simple example to see how the overall feature file looks:

Benefits of Using Gherkin:

Using Gherkin language to write and define the behaviour in your BDD framework has many advantages. Some of the major ones are mentioned below:

1. Gherkin is simple

2. Increases code reusability 

3. Focuses on project requirements

Disadvantages of Using Gherkin:

Every tool and software has limitations and disadvantages, and Gherkin is no different. Here are some of the cons of using Gherkin:

1. Not for all projects

2. Potential Expense

3. It requires a lot of engagement

Conclusion

Thus, behavior driven development has been bridging the gap between developers and businesses for more than a decade now and has successfully made the implementation as close to the behaviour as possible.

As time passed and technology advanced, better alternatives to BDD were introduced. Testsigma is one such tool that uses NLP to let users automate test cases in simple English and does not require coding skills. Non-technical members of the team can easily review these test cases.

Also, the test case creation can begin before the development is completed.

Try Testsigma to enjoy the benefits of BDD without the complexity of maintaining dual layers of code

Frequently Asked Questions

What is a Behaviour Driven Development with Example?

BDD emphasises on how the product works for the end user; in particular, you define your tests as you develop your features. As a result, if your software passes the tests, it includes the necessary components. This is a totally different technique from what is usually used.

Example:

A user forgets their password.

Given: the user is on a page with login boxes.

And: the user has typed “test1” as their username.

When: users click on the “Forgot password?” link

Then: user is directed to the password reset page.

BDD framework is what you use to perform Behaviour driven development, few such frameworks are:

1) Specs

2) Cucumber

3) JBehave

4) SpecFlow

5) Jdave

6) Instinct

What are the three Amigos of BDD?

Business, Developer, and Tester are the three amigos that practice BDD. It is a shift left practice in software development where the Three Amigos meet regularly to discuss how the product will be developed to avoid misunderstandings.

What is the Difference Between BDD & TDD?

BDD:

• It is used for functional tests.
• This development is a team methodology.
• Users or testers create automated specifications.

TDD:

• It is used for unit tests.
• This is a development technique.
• The developers write the tests.

Is Cucumber BDD or TDD?

Cucumber is a BDD-based framework that is an automation tool used to Automate Tests Frameworks written in the BDD (Behavior-Driven Development) manner.

How do you Write BDD Testing Scenarios?

In Gherkin BDD scenarios, some keywords are used to establish the preconditions, test description, expected outcome, etc.

Here are some examples of frequent keywords:

1. Feature.

2. Scenario outline.

3. Given, When, Then, And, (Steps)

4. Background.

5. Scenario

6. Rule

7. Example

Suggested Reading

Cucumber vs Testsigma

Test Driven Development

Defect Tracking Tool