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
“cypress-cucumber-preprocessor”: { “nonGlobalStepDefinitions”: false, “step_definitions”: “cypress/e2e/Tests” } |
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 :
1.Open the site https://testgrid.io/ 2.Click on Sign-in link 3.Enter Email 4, Enter Password 5. Click on Sign In button 6. Verify text “Dashboard” after login to make sure user is logged in 7.Validate the title after login 8.Click on 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 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, 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.
specPattern: “**/*.feature” |
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
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 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.