BDD testing is really a game-changer for bridging communication gaps between developers, testers, and business stakeholders. It is a syntax to simplify the complexity of coding into plain business language for everyone to understand.
In this article, we'll learn about BDD testing in-depth, popular tools, challenges, and its best practices.
BDD testing is an Agile approach to software testing where testers write test cases in simple language that even people without technical expertise can understand. The goal of BDD testing is to increase collaboration between the technical side and the business side of the organization.
The Gherkin language is a unique business-readable language used to describe system behaviors and scenarios. It is structured by three primary statements: Given, When, and Then, with each statement describing a specific aspect of the system.
After articulating the system behavior in Gherkin, BDD testers turn it into a test script that can be understood by the computer.
BDD testing is based on the idea that the tres amigos (i.e., three friends) in software development don’t always share the same perspectives, and a common ground between them must be established to facilitate smooth communication. The tres amigos include:
The traditional approach to testing does not connect the perspectives of the tres amigos. Stakeholders come to the product owner to transfer their requirements, then the product owner explains those requirements to developers and testers. After that, developers translate the requirements into code, while the testers translate them into test cases. It was a lengthy process, and loss in translation can occur, which inevitably leads to misunderstandings.
Instead, the tres amigos come together and have a discussion, then turn the insights into a documentation using a shared language to create a common understanding of the issue at hand. Testers can then use a BDD testing framework to create test cases.
With BDD testing, you can:
However, BDD testing is not without limitations:
Day-to-day BDD activity involves a three-step process: discovery, formulation, and automation. These steps help your team confidently make changes to the system. The code reflects the documentation, which reflects everyone's understanding of the problem.
During the Discovery stage, stakeholders participate in structured conversations called discovery workshops (or more commonly known as brainstorming sessions) where they discuss and reach a mutual agreement on the desired goals. They start by stating the user story or requirement in a concise format, such as “As a [role], I want [goal] so that [benefit].”
After that, they brainstorm examples of how the user story should behave in different scenarios. These examples focus on concrete situations and help to define the expected behavior. The team then writes each example on sticky notes or a digital tool, arranging them in a structured format. A common format includes columns for the example, a brief description, rules or constraints, and any open questions or areas of uncertainty.
This approach is known as “Example Mapping.” Created by the founder of Cucumber, one of the most popular BDD testing frameworks, Example Mapping’s goal is to create a shared understanding of user stories or requirements by breaking them down into smaller, concrete examples for the three amigos to follow.
The issue with Example Mapping is that it does not present information in a structured format, which is something Gherkin was created to address. Once the desired behavior is fully understood, the team moves on to formulating executable specifications using Gherkin.
These specifications are written in a way that stakeholders can easily comprehend and validate, serving as a foundation for creating automated tests. This stage involves defining the feature files, writing scenarios, and identifying the steps required to implement each scenario.
Finally, in the Automation stage, they implement the behavior described in each example, starting with the automated test. The executable specification guides the implementation process.
These steps can be implemented as unit tests or integrated into a larger test suite using a testing framework. The automation process involves mapping each step to the corresponding code and ensuring that the tests accurately reflect the desired behavior. Automation testing allows for efficient and repeatable execution of the tests, reducing the need for manual regression testing, enabling testers to focus on more engaging tasks like exploratory testing.
There are several rules in writing Gherkin statements:
Below are the detailed Gherkin statements to describe the business scenario of “As a customer, I want to be able to place an online order for products and receive real-time updates on the status of my order”
Feature: Online Order Placement and Status Updates
As a customer,
I want to be able to place an online order for products
And receive real-time updates on the status of my order
Scenario: Placing an Online Order
Given I am a registered customer
And I am logged in to the online store
And there are available products for purchase
When I add a product to my cart
And I proceed to the checkout process
And I provide the necessary order details
And I confirm my order
Then my order should be successfully placed
And I should receive an order confirmation email
Scenario: Tracking Order Status
Given I have placed an order
And I have received an order confirmation
When I visit the order tracking page
Then I should see the current status of my order
And the status should be updated in real-time
Scenario: Order Status Notification
Given I have placed an order
And I have opted to receive order status notifications
When there is a change in my order status
Then I should receive a real-time notification
And the notification should include the updated status of my order
The code for this workflow would have been quite complex and lengthy, and non-technical people wouldn’t be able to comprehend any of that to make informed decisions. The focus of the entire BDD feature file centers around the advantages that customers will gain from the software, rather than delving into the software's interface or implementation.
Testers can then start to translate this Gherkin-written user story into an automated test script written in programming languages such as JavaScript, Rust, or Haskell, depending on the context of the project.
Test-driven development (TDD) is an iterative process where code quality is guided and continuously improved through tests. The process of TDD is detailed below:
TDD is essentially about running unit tests in isolation, because then there are no external dependencies on the tests that can influence its results, and developers can confidently use them as guidance for their development. However, the unit tests created in TDD are highly technical, which is why you should incorporate BDD with TDD to bring BDD’s collaborative nature into TDD.
Doing BDD testing in TDD style should slightly differ from the standard process described above.
After the discovery workshop between the tres amigos, for each scenario written in Gherkin developers write a unit test, which will surely fail since no code has yet to be written. They then write the code to make those tests pass, and then repeat. The essence is no different from the standard TDD process, but with the extra steps where business requirements and scenarios are defined, collaboration and communication is significantly improved, and you get the best of both worlds.
BDD testing frameworks are software structures that provide support for implementing BDD practices and automating BDD tests. These frameworks offer features and utilities that support BDD practitioners throughout the STLC: from creation and execution, to management and reporting of BDD-style tests.
BDD testing frameworks play another important role: it allows developers to approach BDD testing in TDD style by providing structure, tooling, and support for writing and executing BDD tests. These frameworks facilitate the mapping of human-readable test scenarios to the corresponding implementation code.
Cucumber is a highly popular BDD testing framework. Initially developed in Ruby, it now supports various programming languages, including Java and JavaScript. Its popularity remains strong within the Ruby developer community due to its familiarity. Some organizations combine Cucumber with Selenium to achieve reliable test automation with an emphasis on plain language. This approach fosters shared understanding, improved collaboration, and scalable web testing across multiple browsers.
Read More: Cucumber Testing: A Detailed Guide
SpecFlow is a highly sought-after BDD framework for .NET. It offers two versions: open-source and premium (SpecFlow+). The open-source version requires a separate unit test runner like MSTest or Unit to execute test scenarios. In contrast, SpecFlow+ includes a built-in runner suitable for BDD testing. The premium version of SpecFlow also provides additional features such as Microsoft Excel integrations, living documentation, and premium support.
Quantum, an open-source BDD testing framework developed by Perfecto, offers organizations a powerful option for expanding automation efforts. Quantum enables stable execution of BDD automated tests in the cloud, ensuring reliability on clean and secure Android/iOS devices and desktop browsers. Users can leverage all the familiar features of Cucumber BDD, including data tables, scenario outlines, examples, and backgrounds.
JBehave is a renowned BDD framework for Java and other JVM languages like Groovy, Kotlin, and Scala. As one of the original BDD frameworks, JBehave holds a strong reputation among developers and test engineers. However, it's worth mentioning that JBehave lacks certain common Gherkin features. Teams seeking a fully compliant Java or JVM-language BDD framework often include Cucumber-JVM in their evaluation.
Cucumber is great for BDD testing, but it provides no support for many other testing types. Instead of relying on Cucumber solely to perform BDD testing, you can turn to a comprehensive testing platform that supports Cucumber for centralized management and extra functionalities.
Read more: Cucumber BDD Automation Testing With Katalon
Katalon is a comprehensive quality management platform that allows QA teams to create tests with no code, manage tests in a centralized repository, execute tests on cloud across a wide range of browsers, and generate in-depth reporting for data-driven decision making. You can perform all test activities across the Software Testing Life Cycle on web, API, desktop, and mobile on Katalon. Katalon can be seamlessly integrated into your CI/CD pipeline to further streamline your testing process.
Katalon supports BDD testing on Cucumber, allowing testers to get the best of both worlds, leveraging the BDD capabilities of Cucumber while utilizing the rich features provided by Katalon:
After downloading Katalon Studio, simply navigate to File > New > BDD Feature File to create a Cucumber feature file in Katalon.
Give your feature file a name. If you check the “Generate sample feature file template,” a full BDD script template written in Gherkin will be created for you to freely edit.
Here is a simple Gherkin scenario as shown below:
Scenario: Login functionality
Given I navigate to the login page
When I enter my username
And I enter my password
And I click on the login button
Then I should be logged in successfully
At this stage, you should see that there is a yellow highlight on each step in the feature file. This occurs because we have not yet created the step definition or test script for each step (i.e., missing glue code – small pieces of code or scripts that connect two technologies together, which are Cucumber and Katalon in this context).
Therefore, the next step involves creating the step definition in the step file. In the left sidebar, navigate to Include > features > scripts > groovy > (default package). Here you can right click, select New > Step Definition and create a Groovy script.
As you can see, each of the BDD steps above have been linked with its corresponding test definition.
After that you can start leveraging the fast test authoring features of Katalon to transform the BDD feature file into a full test script within seconds. There are two notable methods:
Although these are low-code features, Katalon still allows you to view the full script, and you can complete the functions in the step definition file with the respective newly generated code. Finally, navigate to the top toolbar and click Run. Your device will run automatically and after the test is finished you can see the BDD test results in Katalon TestOps.
It is easy to see how the capabilities of Cucumber are significantly expanded with Katalon:
Here is a table that compares the differences between BDD and TDD:
BDD | TDD | |
Focus | Behavior of the system | Functionality of individual units |
Language | Uses business-readable language | Uses programming language constructs |
Audience | Developers, testers, business analysts | Developers, testers |
Collaboration | Encourages collaboration among roles | Primarily developer-focused |
Test Structure | Scenarios and user stories | Test cases and assertions |
Implementation | Top-down approach | Bottom-up approach |
Tools | Cucumber, SpecFlow, JBehave, etc. | JUnit, NUnit, PHPUnit, etc. |
Feedback | Focuses on the system's behavior | Focuses on the correctness of units |
Documentation | Living documentation | Test documentation |
Read More: TDD vs BDD: A Comparison
Yes, BDD testing can be used for non-agile projects. Although BDD is often associated with Agile methodologies like Scrum or Kanban, its principles and practices can be applied to any software development project, regardless of the development methodology being followed.
The key benefits of BDD, such as improved communication, shared understanding, and the ability to drive development based on business requirements, can be highly valuable in non-agile projects. BDD helps to ensure that the system meets the desired behavior and provides clear and unambiguous documentation of the system's functionality.
Yes, since BDD testing itself is a way to improve collaboration in testing, it can be combined with many other testing approaches.
BDD’s distinguishing feature lies in its capacity to integrate the behaviors and actions of stakeholders into the development process, ensuring the creation of software that aligns with their expectations and requirements.
BDD fosters collaboration, facilitating a shared understanding of the software's functionalities and necessities, while eliminating ambiguities and misunderstandings by emphasizing the use of clear language throughout the development process.