Cucumber BDD with Java & Selenium Framework
- saphinrao0
- Jun 3
- 4 min read
Behavior-Driven Development is an approach that uses plain language to define how a system should behave. Instead of writing tests in purely technical language, BDD focuses on user behavior, making it easier for tech and non-tech teams. In this article, we will see how Cucumber BDD works with Java and Selenium, how Gherkin scenarios fit into the framework, and how all come together.
What is BDD?
Behavior-Driven Development is an approach that uses plain language to describe system behavior. BDD enhances communication between technical and non-technical teams by using natural language to describe system behavior.
BDD uses the “Given – When – Then” structure for writing test cases
This structure makes the test case readable, predictable, and easy to maintain. Instead of focusing on how the system works internally, BDD focuses on what the user expects. BDD is not a testing technique. It is a strategy to provide a common language for all stakeholders. BDD reduces the ambiguity in requirements. It ensures QA tests exactly what the business expects.
When teams go with BDD, they spend less time clarifying requirements and more time delivering features that work as intended.
Cucumber
Cucumber is a tool or framework that supports Behavior-Driven Development(BDD). BDD allows you to write test cases in Gherkin syntax. It connects plain language scenarios to executable automation code. It offers the real communication layer on top of a robust testing framework. This can help run tests from the backend to the frontend.
Keywords used in Cucumber: Scenario, Feature, Feature file, Scenario outline, Step Definition
These keywords help structure the test in a way that is easy for anyone to understand.
Feature
Rule
Background
Scenario
Scenario Outline
' * '
Feature and Feature file:
Gherkin file starts with a Feature keyword. A Feature represents a business requirement. A feature file is the entry point to the Cucumber tests. This is a file where you will describe your tests in plain English. Whatever comes after the Feature: keyword is considered the feature description. A feature file can contain a scenario or a list of scenarios.
· Feature files use the .feature extension
· They should be named in lowercase
· Each file groups scenarios for a specific part of the application
Feature file example:

Rule:
The Rule keyword is introduced in the latest version 6 of Cucumber. The rule keyword in Cucumber is especially useful when a single feature file contains multiple business rules or variations of behavior. The Rule keyword helps group related scenarios under a clear business rule, improving readability and structure.
Rule Example:

Background:
The Background keyword in Cucumber is used to define steps that are common to all scenarios within a feature file. Instead of repeating the same Given steps in every scenario, we place them under Background, and Cucumber automatically executes them before each scenario. This keeps feature files clean, readable, and easier to maintain, especially when multiple scenarios share the same setup.
Background Example:

Scenario:
In Cucumber, test cases are represented as Scenarios. Each scenario describes a specific behavior of the system.
Each scenario consists of three parts:
· Given – Pre-condition to the test
· When – Test step execution
· Then - Verifies the output with the expected result
Scenario example:

This makes the test flow easy to understand for anyone reading it.
Scenario outline:
A Scenario Outline is used when you want to run the same scenario with multiple sets os data. It supports parameterization and improves reusability. The multiple arguments passed against the same scenario outline are called Examples, which is another keyword in Cucumber.
Scenario Outline Example:

' * ' :
Cucumber provides several Gherkin keywords, such as Given, When, Then to structure scenarios in a readable, behavior-focused format. However, Cucumber also supports a special keyword asterisk (*). This keyword can replace any of the standard step keywords, and the scenario will still execute the same. The reason for this is that Cucumber does not actually care which keyword you use; it only cares about the step definition that matches the text of the step. The keyword is for humans, the step definition is for the automation engine.
Using * Keyword:

Step Definition:
Step Definitions contain the actual Java and Selenium code that executes the steps written in Gherkin. Each Gherkin step in the feature file maps to a Java method.
Step Definition Example:

Difference between Cucumber & Selenium
Cucumber and Selenium are often used together in automation frameworks, they serve very different purposes. Selenium is a browser automation tool designed to simulate real user actions such as clicking buttons, entering text, navigating pages, and validating UI elements. Its primary focus is on executing automated tests by interacting directly with the web application. Because of this, Selenium requires strong technical skills both for setting up the framework and writing automation scripts. It is generally considered more stable and reliable because it deals directly with WebDriver APIs without additional abstraction layers.
Cucumber, on the other hand, is a BDD tool that focuses on making test cases readable and business-friendly. Instead of writing tests in code, Cucumber allows teams to describe behavior in plain English using Gherkin syntax. This makes scenarios easy for developers, testers, and non-technical stakeholders to understand. However, Cucumber cannot automate anything on its own; it must be integrated with Selenium or another automation tool to execute the steps defined in Gherkin. While Cucumber improves collaboration and clarity, its framework setup is more complex, and maintaining step definitions can become challenging as the test suite grows.
In simple terms, Cucumber defines the behavior, while Selenium performs the behavior. Cucumber answers what should happen from the user's perspective, and Selenium answers how to automate those actions in the browser. Together, they create a powerful combination of readability and automation strength.


