What Is BDD (Behavior Driven Development) Testing?

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.

• The Given statement sets up the initial context for the behavior and defines the starting point of the system.
• The When statement describes the trigger that brings about a change or behavior in the system.
• The Then statement defines the expected outcome that should be observed after the event mentioned in the When statement.

After articulating the system behavior in Gherkin, BDD testers turn it into a test script that can be understood by the computer. 

Why Do We Need BDD Testing?

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:

• Product Owner: representing the business side, they simply want to solve a problem they have.
• Developer: representing the development side, they want to build a solution to solve the problem of the Product Owner.
• Tester: representing the QA side, they want to know if the solution can actually solve the problem, and what can possibly go wrong with the solution.

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.

Advantages of BDD Testing

With BDD testing, you can:

• Have a common language for engineers and stakeholders to communicate about user needs and software solutions.
• Craft user stories and scenarios to define acceptance criteria for specific software features.
• Promote collaboration among users, quality team, product team, and engineers to achieve consensus on the project's goals.
• Reduce uncertainties.
• Enable faster product delivery by the rapid creation of mutually agreed upon automated tests.
• Reduce errors in software implementation by converting business requirements into a clear format for all executed tests.
• Minimize the learning curve and jargon.

Limitations of BDD Testing

However, BDD testing is not without limitations:

• Potentially leads to lengthy stakeholder meetings and the inclusion of all key stakeholders in the BDD process.
• Demands well-prepared software requirements for the Gherkin scripts to accurately express the business needs, which may conflict with the fast-paced nature of Agile teams working from concise specifications.
• Less efficient for small development teams.

Steps To Do BDD Testing

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.

1. Discovery Stage

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.
 

2. Formulation Stage

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.

3. Automation Stage

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.

Examples of Using Gherkin for BDD Testing

There are several rules in writing Gherkin statements:

• Besides Given, When, and Then statements, testers can also use other keywords such as Feature, Rule, Example, And, But, Background, Scenario Outline, Examples to describe the behavior. 
• You should use these keywords at the start of a line.
• Comments are permitted at the start of a new line and begin with optional spaces, followed by a hash sign (#) and text. 
• Indentation can be achieved using spaces or tabs, with a recommended indentation level of two spaces.
   

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. 

Steps To Do BDD Testing In TDD-Style

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:

1. Developers create unit tests before writing code. These tests define code behavior and set a goal for developers (they must code in a way that passes those tests).
2. Run those unit tests with the intention to observe them fail. 
3. Developers write just enough code to pass the test.
4. Create and execute unit tests again.
5. Refactor the existing code to pass the tests while improving design, readability, and maintainability. 
6. Repeat.

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.

What Are BDD Testing Frameworks?

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.

Popular BDD Testing Frameworks

Cucumber

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. 

SpecFlow

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

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

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.

How To Do BDD Testing with Katalon and Cucumber?

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:

• Import BDD feature files into Katalon to leverage its centralized test management features
• Easily create test scripts with Katalon’s low-code test authoring features
• Link BDD steps with test scripts to track test results
• Generate detailed test reports in BDD style

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:

1. Built-in keywords: these are essentially code snippets that you can drag and drop to construct the test case.
2. Record-and-Playback: this feature records the sequence of actions on your screen, retrieves the xPath of the objects you interact with, and turns them into a Selenium script that can be re-executed across multiple environments. Simply put in your destination URL, choose the browser and run.

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:

• Low code, fast test authoring instead of coding test scripts from scratch
• Coding mode available for extra customization of test scripts
• Cross-browser testing and execution for higher test coverage
• Katalon test scripts can be maintained and easily updated through centralized management system, which is less resource intensive than Selenium scripts
• Detailed test result generation in BDD style

Try BDD Testing With Katalon

BDD Testing FAQs

1. What are the key differences between BDD and TDD?

Here is a table that compares the differences between BDD and TDD:
 

Read More: TDD vs BDD: A Comparison

2. Can BDD Testing be used for non-Agile projects?

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.

3. Can BDD Testing be combined with other testing approaches?

Yes, since BDD testing itself is a way to improve collaboration in testing, it can be combined with many other testing approaches. 

4. How does BDD Testing enhance collaboration among team members/stakeholders?

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.

Start Testing With Katalon