Cucumber BDD is a testing framework that lets you write test cases in a human-readable format using Gherkin syntax. It helps both technical and non-technical stakeholders understand the test scenarios and stay aligned. The goal is to clearly define the expected behavior of the application and automate its validation.
In this article, we learn more about the Cucumber BDD framework and how to run a Cucumber BDD test over an automation cloud like TestMu AI (formerly LambdaTest).
Overview of Behavior-Driven Development (BDD)
Behavior-Driven Development (BDD) is a software development practice that specifies an application’s behavior in plain English. Instead of focusing on implementation details, BDD specifies the expected behavior of a system from the user’s perspective, either before or during development.
The benefit of following a BDD approach is that it provides a clear, shared path to drive both development and testing. It improves collaboration between all the people involved in the process. BDD promotes alignment with user expectations by specifying behavior from the user’s perspective, but it does not guarantee implementation correctness. By focusing on “what” the system should do instead of “how”. BDD helps teams to reduce bugs early and build software that aligns closely with business needs.
The BDD methodology mainly has three phases, which are:
- Discovery Phase
- Formulation Phase
- Development Phase
The discovery phase is where the developers, testers, and product owners walk through upcoming features. In this stage, the idea is to understand how the system should behave from the user’s point of view. The goal is simple: get everyone on the same page before writing a single line of code.
The formulation phase is where the behavior is described using structured, human-readable language following the Given–When–Then format defined by Gherkin syntax. The development phase is where you write step definitions that connect these scenarios to real test automation logic.
One of the popular frameworks that implements Behavior-Driven Development (BDD) is Cucumber. It allows you to describe how applications should behave using simple, human-readable language. By writing test scenarios in Gherkin syntax, Cucumber makes it easier for developers and testers to focus on what the software is expected to do.
What is the Cucumber BDD Framework?
Cucumber is a popular testing framework that lets you describe the expected behavior using the Gherkin syntax. Cucumber was created for testing Ruby-based applications. It has grown a lot from that and now supports multiple programming languages, including Java, JavaScript, Python, C#, and others, through various implementations like Cucumber-JVM, Cucumber.js, and Cucumber-cpp.
Test scenarios in Cucumber BDD are written in feature files using the Gherkin syntax, which uses keywords like Given, When, Then, And, and But to describe application behavior. Each feature file contains one or more scenarios that represent specific functionalities. When you run the tests, it reads these feature files, matches each step to its corresponding step definition method, and runs the associated test code.
How to Use Cucumber BDD Framework?
Using Cucumber with BDD is pretty straightforward; you just describe how your app should behave and then turn those descriptions into automated tests.
Let’s break down the core components that make everything work
Installing Cucumber
You can use the language of your choice, but here we will use JavaScript.
Setting Up Cucumber with JavaScript
To use Cucumber BDD in a JavaScript/Node.js project, you typically install the cucumber-js library. It’s available via npm and should be added as a development dependency.
Head over to your project’s location in your terminal and run this command:
npm install –save-dev @cucumber/cucumber
This installs the latest Cucumber CLI and API for Node.js. Make sure you add –save-dev flag in order to keep it as a dev dependency.
The next step is to organise your folder structure. One of the most common formats is to have a separate folder for features and step definitions.
Cucumber-test-automation> cucumber-bdd-TestMu AI > features > login.feature
Cucumber-test-automation> cucumber-bdd-TestMu AI > features > step-definitions > loginSteps.js
The features folder holds .feature files (Gherkin scenarios), and the step_definitions folder, typically placed inside the features folder, contains the corresponding JavaScript files where you write the code that executes each step.
If you are testing web applications, you’ll also need a Selenium WebDriver setup. You can install the necessary Selenium bindings by running the following command.
npm install selenium-webdriver
You can also use a higher-level framework like WebdriverIO with its Cucumber plugin. With everything set up and ready to go, the next step is to start writing your first feature file.
Writing Feature Files
The feature files serve as the foundation of BDD testing. Feature files use a simple, human-readable language called Gherkin to describe application behavior. Each feature file ends with a .feature extension and is present inside the features folder of your project.
The feature file begins with a feature name and an optional description. It’s like a high-level description of the functionality. Under each feature, one or more Scenario blocks specify examples. Each scenario is a sequence of these steps:
- Given: Describes the initial context or state of the system.
- When: Describes the action or event that triggers the behavior.
- Then: Describes the expected outcome after the action takes place.
You can create multiple scenarios in a single feature file or split them into separate files according to the needs of your project.
Each line beginning with Given/When/Then corresponds to a step that Cucumber will execute. Here, the “Given I am on the login page” would be linked to a step definition in code that opens the browser to the login URL.
Now we will implement these steps in JavaScript using step definitions.
Implementing Step Definitions
Once your feature file is written, the next step is to bring it to life with step definitions. Step definitions convert the Gherkin scenarios into your automation code. Each step in your feature file is mapped to a function that performs the test logic. They are the actual functions that run when Cucumber encounters each step in your feature file.
Hooks in Cucumber
Cucumber also provides you with Hooks. They are the special functions that run before or after your test scenarios. They are useful for setting up preconditions or cleaning up after tests, such as launching browsers, resetting state, or logging results.
Some common hooks in Cucumber are:
- Before(): The Before() hook runs before each scenario
- After(): The After() hook runs after each scenario
- AfterAll(): The AfterAll() hook runs once after all tests
Scenario-Level Parallel Execution with Cucumber BDD Framework
Cucumber supports parallel execution at the scenario level, allowing the test runner to execute multiple scenarios simultaneously and even when those scenarios are defined in different feature files. When you have a large suite of end-to-end tests, executing scenarios sequentially becomes a bottleneck. Scenario-level parallelism significantly reduces the total runtime by distributing individual scenarios across multiple worker processes, each running independently and simultaneously.
Parallel execution will drastically reduce test execution time and improve CI/CD efficiency. Since most CI providers bill per build minute, parallel runs ensure faster builds, leading to quicker merges, deployments, and cost savings.
Parallel Execution
Cucumber-JS allows scenario-level parallelism where scenarios, regardless of their feature files, are distributed among worker processes independently.
Multiple Features — Multiple Step Definitions
In this scenario, it involves running multiple feature files in parallel, each potentially using step definitions from multiple files. You can group each feature with its own step definition files. Cucumber will load all features and match each one to the appropriate step definitions, then distribute them across worker processes when you run in parallel.
This architecture allows for maximum flexibility and scalability, as different features can share common step definitions while maintaining their own specific implementations. The parallel execution significantly reduces overall test runtime, making it ideal for large test suites with multiple features covering different areas of your application.
Using Selenium with Cucumber
Cucumber is often used along with Selenium in order to have control over the browser environment. Selenium is the engine behind browser automation. Selenium allows you to simulate real user actions like clicking buttons, entering text, navigating pages, and validating the UI.
The combination of Cucumber and Selenium creates a powerful testing framework that bridges the gap between business requirements and technical implementation.
Setting Up Selenium with JavaScript
First, you will need to install the necessary packages for both Cucumber and Selenium. You can install the selenium-webdriver package from NPM, Yarn or PNPM.
Then, in your step definition files, bring in the necessary modules:
Now you can instantiate a browser instance.
The driver instance exposes methods like .get(url), .findElement(By.name(‘username’)) and more for interacting with the browser.
Running tests
By default, Selenium tests run directly on your machine (one browser at a time). But if you want to run tests in parallel across multiple browsers or environments, you will need something more scalable.
That’s where Selenium Grid comes in. Selenium Grid is a tool that lets you distribute your tests across multiple machines and browsers locally or remotely.
Running tests on a local Selenium Grid really depends on how powerful your machine is. Since each browser instance consumes significant memory and CPU resources, the better your system specifications, the more tests you can run simultaneously without performance degradation.
That’s where cloud-based Selenium Grid solutions shine. TestMu AI (formerly LambdaTest) is an automation testing platform where you can run your Cucumber/Selenium tests across a vast array of browsers, operating systems, and devices without the limitations of local infrastructure.
To run tests on TestMu AI, you need to follow the steps below.
- Set up TestMu AI credentials: Set TestMu AI Username and Access Key in environment variables. You can get those from the accounts section on TestMu AI.
- Configure capabilities. In your test setup code (or a config file), specify the TestMu AI Selenium Hub URL and desired capabilities.
You should also update the code a little bit in order to make this run on TestMu AI. You have to change the WebDriver setup so that it connects to TestMu AI’s cloud grid instead of running tests locally.
Instead of using .forBrowser(‘chrome’), you will need to use .usingServer(…) to point your tests to TestMu AI’s remote Selenium server. You must also define the desired capabilities, such as the browser, platform, and other options, which let TestMu AI know how and where to run your test. In order to see the available options, you can check out the Capabilities Generator to generate the JSON.
Now, when you run the test, it will run on TestMu AI’s hosted Selenium grid.
Limitations of the Cucumber Framework
Performance Overhead
Cucumber tests run significantly slower than unit tests due to the additional parsing layer between Gherkin scenarios and the code execution of the corresponding step definitions.
Each Cucumber scenario spins up the test framework, loads step definitions, and runs the hooks. In a large test suite (hundreds of scenarios), this can lead to slow feedback cycles or sometimes take minutes to run end‑to‑end tests.
Strong Coupling Between Feature Files and Step Definitions
Cucumber matches steps to regex or Cucumber Expressions; there’s a tight coupling between the exact wording in the .feature file and the code that executes. Refactoring one often means you must refactor the other.
Difficulty in Data‑Driven Flows
When your application’s behavior depends on complex, dynamic data like generated tokens, random values, or multi‑step calculations, expressing that cleanly in Gherkin becomes clumsy.
Consider a process where a user logs in, generates a one‑time token, uses that token in a second microservice call, and then validates a dynamic invoice number returned by the system.
Now you need a way in your step definitions to stash the latest token in a global state, interpolate it into another step, and then validate a regex pattern. Your plain-English Gherkin Scenarios are mixed with technical details, which contradicts the whole idea of BDD.
Complexity in Step Definitions
Feature files are supposed to be easy for everyone to read, especially for business users. It is easy to put too much complex logic into the step definitions. Over time, these step definitions can become large and difficult to manage. As a result, the clear line between what the feature is supposed to do and how it’s done gets affected. This makes debugging and maintaining the tests much harder.
Conclusion
Thanks for checking out this blog. In this detailed tutorial on Cucumber.js, you have covered almost everything you need to know to get started with behavior-driven development and test automation. You have also explored real-world use cases of Cucumber, such as writing readable Gherkin scenarios, implementing step definitions, using hooks for setup and teardown, and integrating with Selenium WebDriver for browser automation.
This blog serves as a solid starting point for beginners and guides you toward advanced testing techniques like parallel execution, page object patterns, and cloud-based testing strategies to take your automation skills to the next level.
Happy testing!