BDD framework

Introduction

?


Behavior Driven Development(BDD)

BDD is a software development process that is driven by the behaviour of an application and is sometimes called as an extension of the?Test Driven Development (TDD)?approach.?


BDD came to the fore when the test automation was proving too technical to understand for the non-technical team members and stake-holders. To improve the situation, a layer was introduced that would 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 just create an easy to understand frontend which also can be executed automated test run. This interface is?provided by Testsigma. 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]


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


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.

Image Source

TDD approach helps make an application stable. However, it is difficult to understand the automated tests for non-technical team members and other stakeholders. In order 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 behaviour of the system thus the name?‘Behavior Driven Development’.

Thus, whereas TDD? begins with a focus on the development of unit tests by developers, BDD starts with a focus on specifying the behaviour of the system 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 easily reviewed by anyone in the entire team including QA team, Dev team, Business Analyst, sales team and other stakeholders whereas in the TDD approach, automated test cases are tough to review as they are defined by developers in the programming language being used for development.

Below figure shows the process followed by BDD:

Image Source
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 used in a user story must be a valid scenario explaining the user’s viewpoint and not only just a mere test case.

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

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

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


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:

There are some keywords 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 own 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 is a description of what the application is supposed to do. Feature keyword is also used to group multiple scenarios together.


This isn’t only for testing purposes, but it 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 have a background section as well.


Gherkin Steps

There are some gherkin steps specific keywords that 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 is used to describe 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 is used to describe 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 it is advised to split that kind of scenario into multiple scenarios.


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 in keeping the documentation more 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 have an option to 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 have to 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 need to split them into different feature files.


Scenario Outline

The keyword?Scenario Outline?is used to execute the same scenario multiple times with different sets of 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 with the use of <>? tags. For example:?

Scenario Outline: Eating Bananas

??Given there are <Total>? Bananas

??When I eat <eaten> Bananas

??Then I should have <leftover> Bananas


??Examples:

????| Total | eaten | leftover? |

????|? ? 15 | ? 6 |? ? 9 |

????|? ? 20 | ? 8 | ? 12 |

As discussed before in this article, in a BDD framework, there is a frontend file that uses Gherkin syntax and there is 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 is done corresponding 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:

Image Source:?moelholm

Benefits of Using Gherkin:

There are many advantages of using Gherkin language to write and define the behaviour in your BDD framework. 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 some limitations and disadvantages and Gherkin is no different about it.? 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 business for more than a decade now and has been quite successful in making 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 language and does not require any coding skills. These test cases can be easily reviewed by non-technical members of the team.
Also, the test case creation can begin before the development is completed.n