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

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.

How to Write 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:

Given
When
Then
And
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

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

Frequently Asked Questions

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.

Cucumber vs Testsigma

https://testsigma.com/blog/cucumber-vs-testsigma-behaviour-driven-development-compared/

Test Driven Development

https://testsigma.com/blog/test-driven-development-testsigma/

Defect Tracking Tool

https://testsigma.com/blog/defect-tracking-tools/

Testsigma Blog

Shahid Hasan