Behaviour Driven Development (BDD) is an agile software development practice that establishes collaboration between everyone that is involved in the development of software such as Developers, Testers, and Product Owners.

In BDD, test cases are written in a shared and common language on how the application will behave so that it is easily understood by everyone, thus improving direct communication between tech and non-tech teams. Test cases are written using real-time examples of the actual requirement, this is done to describe how the application should behave in a very simple user/business-focused language. BDD’s business-focused perspective on application behaviour allows teams to create living documentation that is easy to maintain and can be consumed by all team members, including Testers, Developers, and Product Owners.

BDD approach has been evolved from TDD (Test Driven Development) and the primary difference is their scope. TDD has a pure development approach while BDD is a team methodology at large. TDD focuses more on the implementation of a feature whereas BDD focuses more on the system’s behaviour and automation validation of these as Acceptance Tests.

Cucumber and Gherkin

Cucumber is an open-source software testing tool that supports BDD. In Cucumber, the BDD requirements are written in simple English which is defined by the Gherkin language. Gherkin presents the behaviour of the application used, from which Cucumber can generate the acceptance test cases.

Gherkin is a simple, lightweight, and structured language that uses regular spoken language (such as English, French, and around 70+ languages) to describe requirements and scenarios. The Gherkin syntax promotes BDD as it allows Developers, Testers, and Product Owners, and others involved to understand the requirements of the project in plain text files. Gherkin also provides scripts for test automation.

How to write in Gherkin Test

To write Gherkin tests, we first need to understand some of the keywords used, and their nature in practice. Below a list of the most common keywords of the Gherkin syntax.

Feature: The feature is a description of what the software is supposed to do.

Scenario: Scenario represents the basic description of a specific scenario testing the feature.

Background: Background allows you to add some context to the scenario, that runs before each scenario as a pre-condition.

Given: The reference of Given is to put the system in a well-known state before user interaction comes into the picture.

When: The reference of When is to define action performed by the user.

Then: The reference of Then is to see the outcome after the action in when step.

And & But: There are chances we might have multiple Given, When, Then, in such cases, we make the scenario more simple and detailed with the help of And & But

Example of Gherkin test

Let us use a simple example to understand as to how a typical Gherkin test looks like:

Feature: Search feature for users on software testing news UK website
As a techie, I want to search an article related to BDD and Gherkin on software testing news UK website

Scenario: When a user searches, without spelling mistake, for BDD and Gherkin. All the search results with similar keyword should be displayed

Given User is on the home page of https://www.softwaretestingnews.co.uk/

When the User searches for “BDD and Gherkin”

Then search results should be updated with the lists of related articles on “BDD and Gherkin”

Advantages of using BDD

BDD has a wide range of benefits due to its comprehensive and versatile nature. Here are some of the top advantages that teams practicing BDD experience:

• Clarity due to Common Understanding: As BDD diminishes the technical barrier, common language written tests is a benefit for all the members of the team.
• Effectiveness: BDD accelerates the development process. Scenarios are requirements, acceptance criteria, test cases, and test scripts all in one, there is no need to write any other artifact. The modular nature of Gherkin syntax expedites test automation development.
• Automation: BDD frameworks make it easy to turn scenarios into automated tests. The steps are already given by the scenarios, the automation tester just needs to write a method/function to perform each step’s operations. Automation based on scenarios that were used to drive the implementation has a better focus and more relevant assertions. This leads to higher test automation coverage and more relevant test automation scenarios, which reduces regression errors and efforts for manual checks.
• Shift Left testing: Testing earlier means fewer bugs later. In BDD, test case definition inherently becomes part of the requirements phase (for waterfall) or grooming (for Agile). As soon as BDD scenarios are written, testing and automation can theoretically begin.
• Reusable and Flexible: Gherkin steps (Given, When, Then) can be reused between scenarios. The underlying implementation for each step does not change. Automation code becomes very modular. Therefore, scenarios become easier and faster to write and automate as more step definitions are added. Sometimes, new scenarios need nothing more than different step parameters or just one new line. Modular design makes changes to automation code safer.
• Failed Scenarios & Defect debugging made easy: One of the prime benefits is BDD’s ability to troubleshoot failed scenarios and fix bugs. Due to the nature of how test scripts in BDD are written, investigation to find the root cause of failure is much quicker and easier. We can find out exactly at which Gherkin step, the test has failed.

Conclusion

BDD provides an easy understanding of requirements, acceptance criteria, test cases, and test scripts as a single artifact. BDD is beneficial to both simple and complex projects due to its maintainability and robust nature. It offers a comprehensive approach in today’s SDLC (Software Development Life Cycle).

A well-written test does not only make sure that everyone (technical and no technical audience) has understood the test with clarity but also affirms that provided requirement is transformed into the desired product as everyone would have a common understanding.

I have tried and tested BDD and it has proved to be one of the best agile approaches in recent times.

Written by Mansoor Ahmed, Software QA Analyst at NTT Data