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-pre-processor

STEP 4: UPDATE CYPRESS.CONFIG.JS WITH BELOW CODE

Above code configures Cypress to use the ‘Cypress-Cucumber pre-processor’ for end-to-end tests. It sets up Cypress to recognize. feature files as test specifications and pre-processes them using the Cucumber pre-processor 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-folders 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’

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 behaviour of the test scenarios in a behaviour-driven development (BDD) style. Each step definition corresponds to a step in the feature files.

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 Login Page class.