Cypress With Cucumber for Seamless End-To-End Testing

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 behavior 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 behavior: BDD places a high priority on specifying how the user should interact with the program 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 endeavor. Together, developers, testers, and stakeholders establish a common understanding of the functionalities of the program. 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 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 behavior of software’s functionality.

Major Components of Cucumber

The 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 behavior, 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());
   },
 },
});

The 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 the Below Code

“cypress-cucumber-preprocessor”: {
“nonGlobalStepDefinitions”: false,
“step_definitions”: “cypress/e2e/Tests”
}

The 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, and 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 the names “TestGridLoginPage” and “TestGridLoginTest” under the 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 from the TestGrid site. Let’s create a cypress example.

Test Scenario

1. Open the site
2. Click on the sign-in link
3. Enter email
4. Enter password
5. Click on the sign-in button
6. Verify text “Dashboard” after login to make sure the user is logged in
7. Validate the title after login
8. Click on the Codeless link
9. Validate Correct page should be open
10. Finally logout from the application

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 the Below Code in ‘TestGridLoginTest.feature’ File

Feature: Login into the site with valid data
Background: Navigate to the Website
Given I navigate to the Website
Scenario: Login into the application with valid data
When I click on Sign In Link
And I entered valid credential
| email | validpassword |
| xxxxxx@gmail.com | xxxxx@1234 |
And Click on sign in button
Then Validate user is logged in
Then Validate the title after login
When I click on Codeless link
Then Validate Codeless link should be open
When I click logout link

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

Step 8: Create Code Under Step Definition File

The below code defines the step definitions used in conjunction with Cucumber feature files to specify the behavior of the test scenarios in a behavior-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 a 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;

10: Execute the Test Case Locally

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

specPattern: “**/*.feature”

The 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. An example is given below:

Background:
Given I am on the registration page
Scenario: Successful registration with valid details
When I enter valid username “newuser123” and email “newuser@example.com”
And I enter a strong password “Password123”
And I click the register button
Then I should be registered successfully

Scenario: Unsuccessful registration with invalid email
When I enter invalid email “invalidemail”
And I enter a strong password “Password123”
And I click the register button
Then I should see an error message

Leverage Data Tables

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

Scenario Outline: Login with different usernames and passwords
Given I enter the username “<username>” and password “<password>”
When I click the Login button
Then I should see the “<expected_result>” message
Examples:
| username | password | expected_result |
| valid_user | valid_password | Login successful |
| invalid_user | valid_password | Invalid username |
| valid_user | invalid_password | Incorrect password |

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).

Feature: User Login
As a registered user
I want to be able to log in
So that I can access my account

@smoke @regression
Scenario: Login with valid credentials
Given I am on the login page
When I enter valid username “user123” and password “password123”
Then I should be logged in successfully

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 behavior-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.