Cucumber is an open-source tool that supports Behavior-Driven Development (BDD). It allows teams to write test scenarios in a human-readable format, typically using the Gherkin syntax. This syntax allows you to describe application behavior in plain English using a structure of Given, When, and Then steps.
These plain English scripts enable the Product teams to write any new functionality or add clients to the existing scripts to enable regression run against those new clients as well.
Identify Gaps:
Since the automation scripts are developed in a readable format, this enables product, development, and design teams to look at the scenarios covered and provide feedback very early in the automation before going to production.
Better User experience with the product:
The variables that may change or are not finalized can be provided as parameters, which enables anyone (even without coding knowledge) to update anytime in the future. Most of the edge case scenarios can be easily added or updated even after the development is completed for automation if there is any change in the business rules. Thus, all the issues can be identified and fixed before releasing the product to production, which enhances the user experience and time spent to fix production issues on a priority basis.
Code:
Scenario: User is able to filter the result based on Prices
Given User navigated to the home application url
And User Search for product “laptop”
When User enters minimum price as “30000” and maximum price as “40000” mentioned in below table
Then Verify that Search results gets filtered with price range between 30000 and 40000
In the above scenario, if the product “laptop” is not finalized when automation is built, we can automate with this parameter, and later, whenever the requirements are solidified, business or automation engineers can update to the finalized product type (monitor/mac/tab, etc).
Improve the collaboration between various roles in the team:
Sometimes, there may be certain scenarios that Business teams want to be covered in every run due to factors like the impact can be huge, or impacts people who are vulnerable to issues in the application. In those situations, team members can quickly write the scenario in Gherkin language, and the step definition (what each line needs to do — automating the steps) can be performed by the automation team.
Or if the automation team is ahead of the requirements phase, then the automation team can develop the steps, and the scenarios can be written later. Hence, Cucumber enables both ways to be progressing rather than waiting on other teams to be finished with their work.
Code:
Scenario: User is able to search for various products and add each type of products with different prices
Given User navigated to the home application url
When User add the products with defined price range and quantity listed below
| ITEM | PRICE_LESS_THAN | QUANTITY |
| laptop | 40000 | 1 |
| earphone | 1000 | 2 |
| mouse | 2000 | 1 |
Then User cart is updated with the products and quantity
In the above sample code, if the requirements are updated later to include another item, eg: keyboard, the business can simply add the item in new line and run it, so while running the above scenario, when step is run, along with the current items, new item is also looped in to be added to the cart. Thus making lesser dependency of business teams on automation engineers and can be updated easily by any member of the team.
Code:
Scenario Outline: User is able to search multiple products
When User Search for product “
Then Search Result page is displayed
Examples:
| product_name |
| laptop |
| earphone |
| computer |
In situations where we need to repeat the whole test on multiple items, we can make use of Scenario Outline and Examples which enables us to write the tests and include any example later when the development is completed or requirements are changed. In the above example, if the application is later updated to support Monitor then we can simply write “Monitor” in the last line and the script will run the whole scenario on monitor as well. And also if we find any bugs later on any specific product, simply adding that item to run the regression on that product helps to identify bugs on that functionality, making adding a new regression flow on a new product a simple task of specifying the product name.
Integration with other tools:
Cucumber can be easily integrated with any programming languages like Java or Python so this tool fits in any automation team. We can also enable various functionalities like which features need to be tested and when by adding TestNG framework tags. This helps in integrating with CI/CD pipelines like Jenkins and includes the automation runs during deployments for a quick sanity check or regression runs on a daily basis.
Step definition:
The key concept of cucumber is user readable test scenarios which can be achieved by building the step definition. This file integrates the feature file (where cucumber tests are written) steps with the functions that need to be run with each step.
Code:
//***********************************************************************
//Step Defs****************
//***********************************************************************
@Given("User navigated to the home application url")
public void user_navigated_to_the_home_application_url() {
WebDriverFactory.navigateToTheUrl(base_url);
scn.log("Browser navigated to URL: " + base_url);
String expected = "Online Shopping site in USA: Shop Online for Mobiles, Books, " +
"Watches, Shoes and More - Amazon.com";
cmnPageObjects.validatePageTitleMatch(expected);
}
Even if the implementation is not done, anyone can write the feature file steps, which enables the automation engineers to work on the implementation later, like above. It works the other way too, if the steps are known, then this can be implemented before writing the test features.
Reusability:
All the components of the Cucumber functionality is reusable, so if we have developed a step and created a step definition along with the method can be used in any other feature file without the need of rewriting any steps. And if there are multiple pages with different text/identifiers for a button, then a single function can be developed and can be used for all the places by ending the value of the text/identifier of the button as a variable.
Prerequisite for tests:
Using the keyword “Background” we can specify what will be the prerequisite for the whole feature without specifying the same step again and again for every Scenario or Scenario Outline. The steps listed under Background will be run before each Scenario or Scenario Outline.
Code:
Background:
Given the patient is logged into the healthcare portal
In this above example, the user is navigated to the home application url before any of the steps for the Scenario or Scenario Outline are executed.
Best Practices:
There are many practices which help in providing the best end user experiences with Cucumber. It's easy to get carried away with writing the logic without considering the best practices which makes rewriting harder and time consuming when maintenance comes due to business changes or newer functionality is being added or bugs in the application. Hence highlighting few key points are as follows:
· Write clear, short, user behavior-focused scenarios.
· Use Gherkin language (Given, When, Then, And) in plain English (non-technical).
· Keep Scenarios short with one behavior per scenario, avoiding long and multiple outcomes (split them).
· Make use of Keyword Background and include the necessary steps under this instead of repeating for every scenario.
· Apply tags as needed for the feature file, eg: @smoke, @regression, @diabetic-feature, @chronic-user etc.
· Reuse step definitions wisely and parameterize if needed.
· Name feature files and scenarios appropriately. The feature should be what is being tested, and the Scenario should be a specific behavior.
· Make use of Page Object Model (POM) and keep UI selectors separate from the test steps.
· Feature files should only describe what the user does, and not how it's done (don’t include the logic here, use step definitions for that).
· Always plan to integrate Cucumber tests into CI/CD build pipeline and kickoff the tests upon every push or pull request to catch issues early.
Metrics:
With the increasing demands from customers, implementing Cucumber as BDD in the automation process helps to meet the demands in the Agile environment, shift left testing, and collaborate early in the development cycle. Adoption of Cucumber has increased significantly, especially in Healthcare, Banking, Insurance, and government sectors to enhance the traceability and audit.
Cucumber, being an open source and gaining a lot of traction, more features are being added, which now include API and microservices automation validation, and not limited to UI automation. Cucumber is expanding beyond the original Ruby and Java and now includes Cypress, Karate, Node.js, JavaScript and many more.
· Return on Investment can be quantifiable due to Reduced Production Defect Leakage by 30%.
· New developers or automation engineers can be onboarded to the project quickly, which increases the productivity and reduces the understanding of the project time by at least 4 weeks, based on complexity can go as high as 2 months.
· Reusability of test steps and parameterized step definitions saves the efforts needed, enabling faster automation development and faster releases by 15%.
· Faster regression execution times and enables targeted testing using tags results in 50% quicker execution times.
With all the above benefits it's clear the ROI starts to payback within 2 quarters of proper implementation with good planning ahead.
Adoption by Bigger organizations:
While it is clear that using Cucumber helps in bridging the communication between business and technical teams, due to the wide adoption in various industries like Banking & Finance, Retail & E-Commerce, Healthcare & Insurance, Media & Entertainment, and Tech, made this a convenient tool for development and testing processes.
Some major organizations using Cucumber are: Google, Atlassian, Spotify, Salesforce, ThoughtWorks, BBC, Capgemini, Adobe, RBS, Airbnb, and many more.
Cucumber enables automating Electronic Health Records (EHR) systems, Health Insurance Platforms, Healthcare tech, telehealth, and patient engagement systems much quicker and accelerates the delivery of high-quality, reliable products. Due to these benefits, Cucumber has quickly become the go-to tool in Healthcare industries and is being used widely in Health-Tech companies like Oracle Health, Teladoc Health, Zocdoc, Epic Systems, HealthEdge, Flatiron Health, Oscar Health, Philips Healthcare etc.
Addresses gaps, Selenium vs Cucumber:
Selenium and Cucumber are the two major open-source automation tools available in the market. But the purpose of both of them are different. The purpose of Selenium is to identify elements for UI testing, and this will be the tool used either standalone to write bigger program-level automation tests or make use of Cucumber, which is a BDD framework that enables to write readable tests.
The focus of Selenium is on the implementation level and how things are tested, whereas for Cucumber, it is at the behavior level and what is being tested.
One key advantage of Cucumber is that enables Developers, or Automation Engineers, or BAs, product owners (anyone non-technical) to update the tests where as Selenium can only be done by Developers or Automation Engineers due to code being developed in programming languages, unlike Cucumber, which uses Plain English language (Gherkin).
Due to all these benefits, Cucumber needs less documentation and promotes reusable steps and patterns, facilitates collaboration in Agile teams, easy to align with specifications, clear traceability of requirements, easy to maintain, structured test suites.
However, Cucumber can’t be standalone and needs Selenium at the implementation level (step definition level) to interact with automation code with UI elements.
Future Scope and Scalability:
As Agile and DevOps usage is increasing widely, the need for business-readable automation raises, which lays the path to implement Cucumber in projects. Increasing use in API, Microservices, and contract testing, and extending the influence of tools like Karate and Rest-Assured make Cucumber a more obvious choice to be added to the project. With the rise of Natural Language Processing (NLP) and Artificial Intelligence (AI) advancements, enabling automated generation and maintenance of feature files well-suited to integrate them with Automation.
Support of the project across multiple platforms, operating systems and devices makes adding the newly supported combination an ease of performing the whole regression by adding the example in the feature file which will be a living document which can be updated based on the need by business teams or product owners without involving Developers or Automation Engineers.
Scalability is another primary benefit of Cucumber which easily integrates with other tools, enabling this tool to be widely accepted across various tech stack tools for any given project. This enables additional features like parallel execution, test management integration, documentation plugins, cloud execution, CI/CD integration, tagging and filtering.
Workflow Summary:
The first feature file exists with the feature we are going to automate, followed by all the scenarios implemented in this feature. This feature will have the tags, which can be used to request when integrated with CI/CD to specify specific functionality (tags) to be run rather than running the whole feature in the project. And there can be multiple features for the same tag ,and also one feature can have multiple tags too. This enables us to specify exact functionality that is covered across multiple features that can be included in that specific run we are targeting.
Then we have scenarios which have Gherkin syntaxes: Background, Scenario Outline, Scenario, Given, When, Then, And, Examples. This can be used in combination to specify the flow we need to automate.
Finally, the most important part is to write the step definition, which determines what functions/methods need to be called for each line on the feature file. And we can have Java/Python files to write the calling methods/functions, which makes execution/update of the Cucumber Feature file an easy step for anyone, even without any knowledge of coding/automation.
Workflow Example:
In the Healthcare industry, traceability of requirements to feature files to tests is key as the impact will be directly on the users, often those who need it the most. A feature file lists all the Scenarios/Scenario outlines that include the steps that are tested.
As an example, a feature file is trying to automate a scenario where a patient is able to search for a specialist in a specific city and schedule the appointment during the available time slot, then verify that the appointment is scheduled successfully and the patient receives the confirmation email. The feature file looks as below:
Code:
ScheduleAppointment.feature
Feature: Appointment booking
# As a registered patient,
# I want to book an appointment with a doctor,
# So that I can receive medical consultation.
Background:
Given the patient is logged into the healthcare portal
Scenario Outline: Successful appointment booking
When the patient searches for a "
And selects a doctor with available slots
And chooses an available time slot "
And confirms the appointment
Then the appointment should be booked successfully
And the patient should receive a confirmation email
Examples:
| specialty | city | time |
| Dermatologist | New York | 10:00 AM |
| Cardiologist | Chicago | 2:30 PM |
| Pediatrician | San Diego | 9:00 AM |
Scenario: Booking attempt with no available slots
When the patient searches for a "Dentist" in "Boston"
And selects a doctor with no available slots
Then the system should display "No available appointments"
Then step definition is created, which can be the linkage between the above steps and what exact code needs to be called in for a specific step, with what parameters. This looks as follows:
Code:
AppointmentStepDefs.java:
package com.visionit.automation.stepdefs;
import …
public class AppointmentStepDefs {
@Given("the patient is logged into the healthcare portal")
public void patientIsLoggedIn() {
loginPage.loginAsPatient("[email protected]", "securePass123");
}
@When("the patient searches for a {string} in {string}")
public void searchDoctor(String specialty, String city) {
searchPage.searchDoctor(specialty, city);
}
@When("selects a doctor with available slots")
public void selectDoctorWithSlots() {
searchPage.selectAvailableDoctor();
}
@When("chooses an available time slot")
public void chooseTimeSlot() {
appointmentPage.selectTimeSlot("10:00 AM");
}
@When("confirms the appointment")
public void confirmAppointment() {
appointmentPage.confirmBooking();
}
@Then("the appointment should be booked successfully")
public void verifyBookingSuccess() {
assertTrue(confirmationPage.isBookingSuccessful());
}
@And("chooses an available time slot {string}")
public void choosesAnAvailableTimeSlot(String arg0) {
}
@And("selects a doctor with no available slots")
public void selectsADoctorWithNoAvailableSlots() {
}
}
Finally, each method is implemented by the automation engineering teams, which is the more technical part, and this can be developed without the dependency on the requirements or step definition. And later these classes can be linked using a step definition. So this enables early automation development.
Code:
PatientLogin.java
package com.visionit.automation.pageobjects;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class PatientLogin {
private WebDriver driver;
private By patient_login_email = By.id("s-refinements");
private By patient_login_pass = By.xpath("//a[@class='a-link-normal a-text-normal']");
public PatientLogin(WebDriver driver){
this.driver = driver;
}
public void loginAsPatient(String mail, String securePass123) {
driver.findElement(patient_login_email).sendKeys(mail);
driver.findElement(patient_login_pass).sendKeys(mail);
}
}
Later, if the system allows scheduling appointments in other specialties or cities, then any business team can easily update the feature file and run the automation without the need for any updates from the automation team. This not only runs the newly added flow but will run through all the existing scenarios. Thus enabling the quicker automation and delivering a quality product to the users, making the software ready for the users swiftly.
Conclusion:
With the current dynamically changing requirements from the organizations due to swift changes to the user expectations, Cucumber provides a fine interface to the business to look at the current functionality and update without relying on the engineering team. This also provides clear expectations from engineering teams on what the requirements are from Product teams, rather than relying on some documents that keep updating.
References
[1] R. B. Bahaweres et al., “Behavior-driven development (BDD) Cucumber Katalon for Automation GUI testing case CURA and Swag Labs,” 2020 International Conference on Informatics, Multimedia, Cyber and Information System (ICIMCIS), Jakarta, Indonesia, 2020, pp. 87–92.
[2] Y. Sangeetha, S. Affroz and G. V. Vardhan, “Video Testing Automation with the Cucumber Framework,” 2024 5th International Conference on Data Intelligence and Cognitive Informatics (ICDICI), Tirunelveli, India, 2024, pp. 667–670.
[3] X. Liu, “Improving generation method for test pattern based on BDD learning,” IEEE 2011 10th International Conference on Electronic Measurement & Instruments, Chengdu, China, 2011, pp. 200–203.
[4] R. Thompson, “Behavior-Driven Development: Using AI for Automating User Stories and Test Cases,” Computer Science Review, vol. 35, no. 2, pp. 80–94, Mar. 2024.
[5] L. Mishra and S. K. Nayak, “A comparative analysis of test-driven development and behavior-driven development in CI/CD pipelines: Enhancing software quality and delivery speed,” Well Testing Journal, Sep. 30, 2022
[6] Y. Liu and E. Martin, “Continuous Integration and BDD: A Synergistic Approach to Test Automation,” Journal of Continuous Software Testing, vol. 15, no. 1, pp. 35–47, 2017.
[7] J. Smith and A. Doe, “Enhancing Agile Testing with Behavior-Driven Development: A Case Study,” Journal of Software Quality Assurance, vol. 12, no. 3, pp. 45–60, 2015.
