Ask Sawal

Discussion Forum
Notification Icon1
Write Answer Icon
Add Question Icon

why bdd framework is used?

3 Answer(s) Available
Answer # 1 #

Gherkin: In BDD, the scenarios are written in a language named Gherkin. Gherkin uses a simple syntax and keywords are easily understood by anyone like business users and stakeholders. The feature files which store the scenarios under test are written in Gherkin. Gherkin files should have the .feature file extension. Every feature file contains an individual scenario under test.

Features: Feature is a use case that describes the module under test. The feature is composed of the following details.

Scenario: A scenario is a series of steps involved in the test execution.

Scenario Outline: Used where test data is replaced with multiple sets of data for each run of a test script.

As an example of an implementation of the test script using Cucumber, we are going to use a maven project in Selenium Webdriver. Before we start with the implementation, we need to add the dependency for Cucumber in pom.xml as we are using a maven project in this scenario. Here we are covering two scenarios.

In this scenario we check the login functionality with a single user:

Below is the class for multiple sets of data to check the login functionality for a single user.

Functionality Methods are defined in this class:


Feature file: Steps for the scenario is written in this class:


Runner class: Class to run the feature file:

4. Results in Junit

Below are the Feature file run results in the Junit:

5. Test results in Console Window

Below are the test results in the Console window:

Let us see the same implementation using multiple sets of data in the below scenario:

In this scenario, we check the login functionality with multiple users:

Below is the class for multiple data sets to check the login functionality for multiple users.


Methods for the functionality are defined in this class:

Here we define the step as:

@When ("^User enters the username as \"( *)\"$")

public void enter_the_username(String ar1) {


driver.findElement("user-name")).sendKeys(ar1); }

Here \"(*)\"$" denotes the user expression for multiple sets of data

The method “enter_the_username” takes String \"(*)\"$" as an argument, which is passed from the examples during runtime.


Feature file: Steps for the scenario is written in this class:

Scenario Outline is the tag name used for testing multiple sets of data.

Examples section: To define the multiple data sets.

Here the “” and <”password”> are replaced with the username and password combinations mentioned in the Examples section


|  username                       | password |

| standard_user                 | secret_sauce |

| performance_glitch_user       | secret_sauce|


Runner class: Class to run the Feature file.

4. Results in Junit

Below are the Feature file run results in the Junit:

5.Test Results in the Console window

Below are the test results in the Console window:

Implementing BDD Framework Using Cucumber is an effective solution as it enables testers to perform and write automated test scripts in natural language, which makes it easier for stakeholders and developers to have a better understanding of test cases. Moreover, it also offers greater flexibility to code in any language like Java, Python, Perl, etc.

Mir Sagar
Industrial Relations Specialist
Answer # 2 #

I can sympathize with these sentiments, especially for those who have participated in projects where BDD was done poorly. Even if a team isn’t doing full behavior-driven development practices, I still assert that BDD test automation frameworks are better than traditional test frameworks for most feature testing (above-unit, black box). Here are reasons why.

Test cases and test code are separate concerns. I should be able to design, discuss, and digest a test case without ever touching code. We describe features in plain language, and so we should also describe tests in plain language. Step definitions are nothing more than the automation behind the test case steps. Traditional test frameworks simply don’t have this separation of concerns, even if test methods are loaded with comments.

BDD frameworks enforce good structure and layers for automation. There are designated places for test cases, step definitions, and support classes. The framework encourages good practices. Traditional test framework, however, are much more free-form. Programmers can do scary and stupid things with test classes. Functionally, a traditional test framework can still be structured well with layers and support classes, but it’s not required. Based on my experiences seeing less experienced automationeers shoving everything into Frankenstein’ed test methods, I much prefer to have the guide rails of a BDD framework.

Steps are the building blocks of test cases, and test cases almost always have the same steps. BDD frameworks identify the step as a unique concern. One step with its definition can be used by any scenario, and steps can be parametrized for flexibility. This creates a “snowball” effect once enough steps have been developed: new tests may not require any new automation code! Traditional test frameworks simply don’t have this mechanism. It could be implemented by calling functions and classes outside of test classes, but not all automationeers are disciplined to do so, and everyone who does it will do it differently.

Good frameworks handle cross-cutting concerns automatically. Things like logging, dependency injection, and cleanup shouldn’t interfere with test cases. BDD frameworks provide hooks to insert extra logic for these concerns around steps, scenarios, features, and even the whole test suite. Hooks can squeeze into steps because the framework is structured around steps. For example, hooks can automatically log steps to Extent Reports, instead of forcing programmers to write explicit logging calls in each test method.

Nothing ruins your day like an illegible code review on features you don’t know. You are responsible for providing valuable feedback, but you can’t figure out what’s going on in the short amount of time you can dedicate to the review. Good Gherkin, however, makes it easy. A reviewer can review the test case apart from any code first to make sure it is a good test case. At this level, the reviewer could even be a non-technical person like a product owner. Then, the reviewer can either send the test case back with suggestions or, if the test case passes muster, dig deeper into the automation code.

It can be hard to onboard new team members. They have so much to learn about the product, the code base, and the team practices. If tests are written using a BDD framework, then newbies can learn the features simply by reading the behavior specs. New automationeers likewise can rely on existing steps both for reuse and for examples as they develop new tests.

auhmkf Mohd
Answer # 3 #

Behavior Driven Development (BDD) Framework enables software testers to complete test scripting in plain English. BDD mainly focuses on the behavior of the product and user acceptance criteria. Cucumber is one of the best tools used to develop in the BDD Framework.

Cotton Cera
Chief Growth Officer