A Comprehensive Guide to BDD Testing with Cypress and Cucumber (2024)

Cypress with cucumber framework is a popular combination for development also in recent years it has gained significant popularity among the “three amigos” (Business, Testing, and Developers). Cucumber helps non-technical stakeholders, such as business analysts and product owners to understand test scenarios written in natural language using Gherkin syntax. This makes it easier for developers, QA engineers, and business stakeholders to collaborate.

Cucumber’s Gherkin syntax makes test scenarios easier to read and understand. As a result, test cases are easier to understand and maintain as the project progresses. When combined, Cypress and Cucumber offer an efficient automated testing solution that lets you create expressive, reusable tests that run consistently and fast in the browser.

About Cypress

Cypress is a modern web-based end-to-end testing framework. For writing and running tests, it offers a quick, dependable, and user-friendly environment. Cypress provides real-time feedback while tests are running and lets you execute actions and assertions right within the browser. Its functions include an integrated test runner, time travel debugging, and automated waiting.

Cypress handles the task of executing your tests, without the need for additional tools or intricate configurations. Compared to traditional tools, tests run directly within the browser, offering a more realistic testing environment and quicker feedback. Waiting for items to load or for operations to finish automatically is handled by Cypress.

About BDD

Behavior-Driven Development, or BDD, is an approach to software development that places a strong emphasis on cooperation, open communication, and an awareness of the perspective of the user. To describe and validate the expected behavior of the application, it encourages developers, testers, and stakeholders (product managers, business analysts, etc.) to collaborate throughout the development process.

The focus of Behavior-Driven Development (BDD) is on developing tests that closely mirror the viewpoints of end users. To do this, test scenarios based on user journeys and the behaviour of the system must be created. BDD documents these test cases using a syntax similar to that of the English language, which improves comprehension and accessibility for stakeholders.

There are three basic principles of BDD

• Emphasis on Behaviour: BDD places a high priority on specifying how the user should interact with the programme in particular situations. With this method, the emphasis is shifted from “how the code works” to “what the user can do with it.”
• Working together: BDD is a team endeavour. Together, developers, testers, and stakeholders establish a common understanding of the functionalities of the programme. Writing BDD specs, doing workshops, and having conversations are common ways to accomplish this.
• Natural Language: BDD specifications are written in standard English, frequently in the Gherkin format. This makes them more comprehensible to all parties, irrespective of their level of technical expertise.Gherkin uses keywords like “Given”, “When”, “Then” and “And” to describe the steps involved in a user interaction and the expected outcome.

About Cucumber

There are several frameworks that support BDD by providing tools to interpret Gherkin specifications and automate tests based on them. Cucumber is one of the most popular BDD frameworks. Cucumber supports BDD used to develop test cases for the behaviour of software’s functionality.

Major Component of Cucumber

Cucumber BDD (Behavior-Driven Development) framework mainly consists of three major parts:

Feature File

Feature files, which provide a plain-text description of the system’s behaviour, are written in a human-readable format, typically using Gherkin syntax. Usually, these files include scenarios that describe different applications’ use cases or functionality from the viewpoint of the end user. The steps in each scenario are described in the Given-When-Then format and explain the intended results, the actions, and the preconditions in turn.

Step Definitions

Between feature files and the actual automation code, step definitions operate as a bridge. Each step in the feature files is mapped to the appropriate automation code, and they are implemented in programming languages like Java, JavaScript, Ruby, and others. Automate scripts are executed based on how the step definitions understand the Gherkin steps.

Automation Code / Test Script:

The automation code is responsible for executing the steps defined in the feature files and verifying that the system behaves as expected. These scripts are typically organized into reusable methods and classes to maintain code readability and scalability.

Cypress and Cucumber Together

Cypress and Cucumber work well together because they combine the structured, human-readable format of Cucumber feature files with the powerful testing capabilities of Cypress. Teams can use this integration to construct collaborative, expressive, and manageable test suites by utilizing the advantages of both tools.

Cypress Cucumber setup

Below are the steps to integrate Cypress with Cucumber.

Step 1 : Generate package.json

• Create a project, naming it e.g cypress_cucumber_testgrid
• Use the command npm init to create a package.json file.

Step 2 : Install Cypress

In the project folder, run > npm install cypress –save-dev to install Cypress. We can see the latest Cypress version is installed, reflected below in the package.json file. When writing this blog the latest version of Cypress is 13.7.2.

Step 3 : Install Cucumber

To install Cucumber, run this command. npm install –save-dev cypress-cucumber-preprocessor

Step 4 : Update cypress.config.js with below code

const { defineConfig } = require("cypress");const cucumber = require("cypress-cucumber-preprocessor").default;module.exports = defineConfig({ e2e: { specPattern: "**/*.feature", setupNodeEvents(on, config) { on("file:preprocessor", cucumber()); }, },});

Above code configures Cypress to use the ‘Cypress-Cucumber preprocessor’ for end-to-end tests. It sets up Cypress to recognize .feature files as test specifications and preprocesses them using the Cucumber preprocessor before execution.

Step 5 : Update package.json with below code

Above configuration specifies that Cypress should look for step definitions (Cucumber test steps) in the directory “cypress/e2e/Tests” and assumes that step definitions are globally accessible.

Step 6: Create Folder structure

We have installed Cypress,Cucumber and done other required set-up. The next step is to create the test cases. Create two folders under the e2e folder. Let’s give names Pages and Tests.

Create two sub-folder with name “TestGridLoginPage” and “TestGridLoginTest” under Pages and Tests subfolder. Create TWO .spec file under (TestGridLoginPage -> TestGridLoginPage.cy.js and TestGridLoginTest-> TestGridLoginTest.cy.js)

For demo purposes, we are taking the example of the site https://testgrid.io/ . Let’s create a cypress example.

Test Scenario :

Step 7 : Create .feature file

We have created the Test and Page folder now time to create the feature file. At the Tests folder level, create the feature files with the name ‘TestGridLoginTest.feature’

Add below code in ‘TestGridLoginTest.feature’ file

So far we have created Page, Tests class and .feature file, next step is to create the step definition and various methods.

Step 8 : Create Code under step definition file

Below code defines the step definitions used in conjunction with Cucumber feature files to specify the behavior of the test scenarios in a behaviour-driven development (BDD) style. Each step definition corresponds to a step in the feature files.

/// <reference types="cypress" />import { Given, When, Then, And } from "cypress-cucumber-preprocessor/steps";import login from "../../Pages/TestGridLoginPage/TestGridLoginPage.cy";Given("I navigate to the Website", () => {login.enterURL();});When("I click on Sign In Link", () => {login.clickSignInLink();});When("I entered valid credential", (datatable) => {datatable.hashes().forEach((element) => { login.enterEmailPassword(element.email, element.validpassword);});});When("User click on sign in button", () => {login.clickSignButton();});Then("Validate user is logged in", () => {login.verifyUserLoggedIn();});Then("Validate the title after login", () => {login.verifyPageTitle();});When("I click on Codeless link", () => {login.verifyCodelessLink();});Then("Validate Codeless link should be open", () => {login.verifyCodelessLinkOpen();});When("I click logout link", () => {login.clickLogoutLink();});

Step 9 : Create Method for Step definitions

The below code defines a page object model for a login page in a Cypress test suite. It provides methods for interacting with various elements on the page. These methods encapsulate the actions a user would perform on the login page during testing. Finally, it exports an instance of the LoginPage class.

class LoginPage {enterURL() { cy.visit("https://testgrid.io/");}clickSignInLink() { cy.get('[title="Sign in"]').click(); return this;}enterEmailPassword(username, password) { cy.get("#email").clear().type(username); cy.get("#password").clear().type(password); return this;}clickSignButton() { cy.get(".signin-button").click(); return this;}verifyPageTitle() { return cy.title().should("eq", "TestGrid | The Cloud Based Mobile Automated Testing Platform on Real iOS and Android Devices");}verifyUserLoggedIn() { return cy.contains('Dashboard')}verifyCodelessLink() { return cy.get("#tgtestcase").click();}verifyCodelessLinkOpen() { return cy.contains("Lets get you started with codeless automation");}clickLogoutLink() { cy.get("[data-toggle='dropdown']").click(); cy.contains("Logout").click(); return}}const login = new LoginPage();export default login;

Step 10 : Execute test case locally

To execute only the .feature file you have to add the below line in cypress.config.js file under e2e.

Above setting specifies that Cypress should look for test specifications (.feature files) in all directories and subdirectories recursively.

Run the command : yarn cypress open and execute the .feature file

Below are some of the screenshots of executing the test cases locally

Cucumber Best Practices

Below are some of the best practices of Cucumber/BDD

Reusable Step Definitions:

Make reusable step definitions to help with maintainability and prevent duplication. Define generic steps that can be reused across multiple scenarios and features.

Use of Background: Use the Background keyword to define steps that are common to all scenarios within a feature. This avoids repetition and keeps scenarios focused. Example given below

Leverage Data Tables: Manage complex test data efficiently using Data Tables embedded within Scenarios.

Use Declarative Style:

Describe actions in terms of anticipated results to improve clarity.

• Example (Imperative): “When I click the Login button”
• Reframe (Declarative): “When I submit the login form”

Avert Conjunctive Steps:

For better readability and maintainability, divide complicated steps into smaller atomic steps.

Example (Instead of): “When I enter the username ‘john’ and password ‘secret'”

Do (Preferably):

“When I enter the username ‘john'”

“And I enter the password ‘secret'”

Use Tags:

Organize Scenarios using tags for filtering, prioritization, or execution based on specific criteria (e.g., smoke tests, regression tests).

Wrap Up

To sum up, Cypress and Cucumber work well together to automate end-to-end (E2E) testing. When it comes to designing and running tests, Cypress offers an easy-to-use interface, while Cucumber lets you define those tests in a behaviour-driven, human-readable language. The combination of Cypress’s powerful debugging capabilities and Cucumber’s support for data-driven testing makes it easier to identify and correct issues early in the development process.