Cypress Tests in BDD Style

Behavior-driven development is an Agile software development process that promotes collaboration between developers, software testers (QA), and the non-technical, business side in a software development process. The outcomes of their collaboration are structured behavior stories which are requirements for product owners, acceptance criteria for developers, description for stakeholders, test cases, and automation scripts for testers.
If you write your automated tests in Cypress and you would like to run them in BDD stories style, you will need to do some additional steps:
1) First, you need to install cypress with cucumber preprocessor module with this command:
$ npm install cypress cucumber cypress-cucumber-preprocessor

2) Then you need to define in your package.json how will you open Cypress:

“scripts”: {
    “cypress-run-cucumber”: “cypress run --config-file cypress/cypress-cucumber.json”
}

Now you can simply start cypress with command npm cypress-run-cucumber

This is our example of cypress-cucumber.json:

{
   “baseUrl”: “http://localhost:3000”,
   “integrationFolder”: “cypress/tests/BDD”,
   “pluginsFile”: “cypress/plugins/cucumber-plugins.js”
}

And our cucumber-plugins.js looks like this:

const cucumber = require(“cypress-cucumber-preprocessor”).default;
module.exports = (on, config) => {
//on is used to hook into various events Cypress emits
   //config is the resolved Cypress config
   on(“file:preprocessor”, cucumber());
   return Object.assign({}, config, {
       fixturesFolder: “cypress/fixtures”,
       integrationFolder: “cypress/tests/BDD”,
       screenshotsFolder: “cypress/screenshots”,
       videosFolder: “cypress/videos”,
       supportFile: “cypress/support/index.js”,
   });
}; 

3) Also, in your package.json file you should define the path to your step definition:

“cypress-cucumber-preprocessor”: {
        “nonGlobalStepDefinitions”: true,
        “step_definitions”: “cypress/tests/BDD”
    }

4) It is also important to create .feature and .js file with the same name, where .js file must be in a folder, also with the same name. So, for example, you will have:

• login.feature
• login (folder)
  • login.js

In login.feature file you can simply paste the BDD story which was the outcome of your team collaboration and in login.js file you should define the steps with Cypress for that story.
Example:
This is your login.feature file:

Feature: User Login
  In order to use the application
  As a user
  I need to be logged in
    Scenario: User logs in with correct credentials
    Given the user is on the login page
    When the user tries to login with correct credentials
    Then he should be redirected to the homepage

This is your login.js file:

import {
    Given, When,Then,
} from “cypress-cucumber-preprocessor/steps”;
Given(/^the user is on login page$/, function () {
    cy.visit(“/login”);
    cy.url().should(“include”, “/login”);
});
When(/^the user tries to login with correct credentials$/, function () {
    cy.get(“[data-test=email-input]“).type(“[e-mail]”);
    cy.get(“[data-test=pw-input]“).type(“test123”);
    cy.get(“[data-test=submit]“).click();
});
Then(/^he should be redirected to the homepage$/, function () {
    cy.url().should(“include”, “/home”);
});

Feel free to comment below if you need any additional explanation or you would like to share your experience on this topic.

Comments

[Damaso Fernandez]

I've a problem with this cucumber and cypress implementation, I have 2 scenarios from the same feature, where this 2 scenarios share 1 step in common, but the issue is that this step that they have in common, it writes different data, this step made the same thing but with different data, and my issue is that always I run this tests, the 2nd scenario re-runs the step of the first scenario, I hope I explain my self in correct way, but please I'll be very glad to get your answer, thank you in advanced

[Ajdin Mustafić]

Hi @Damaso! I understand what you mean but can you give me an example of how different data does it write? Also, you can double-check if the 2nd scenario writes different data because the 1st scenario already wrote some things that can not be written again.

[Dan Greene]

This is pretty interesting stuff. Now that you’ve tried it a while, have you or your team found any issues with the approach?

I’m not personally a fan of BDD testing since I feel that it abstracts away the real issues of testing and therefore it makes it harder to diagnose a failing test. But I’m 100% willing to be converted.