Introduction
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 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 is Behavior Driven Development and the purpose it serves in detail below.
Behavior Driven Development(BDD)
BDD is a software development process that is driven by the behavior of an application and is sometimes called as an extension of the Test Driven Development (TDD) approach.
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.
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 behavior 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 behavior 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:
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 behavior 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 behavior 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 BDD
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
BDD 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 behavior 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 behavior 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 behavior 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 behavior 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 behavior of the system against the step definition. Below is a simple example to see how the overall feature file looks:
Image Source: https://moelholm.com/img/2016-10-15-gherkin-tests.png
Benefits of Using Gherkin:
There are many advantages of using Gherkin language to write and define the behavior 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, BDD 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 behavior 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.
Testsigma offers all the advantages of BDD minus the disadvantages.
