DEV Community

Cover image for Cypress testing. 5 tips you may find useful.
Vlad R
Vlad R

Posted on • Updated on

Cypress testing. 5 tips you may find useful.

Table Of Contents:

I suppose in this article that you've already used cypress before so you understand the basics.

 

Environment variables

Today mostly while building a web app we all try to use at least two environments. It helps us to ensure that all new changes deployed from previous environments are working as intended before they will be pushed to production. And you probably have different databases, api endpoints and variables for each environment. So,

When it comes to cypress, you can also have a separate config file for each environment.

File structure and file names are optional:

/src/cypress/config
                  /test.json
                  /staging.json
                  /production.json
Enter fullscreen mode Exit fullscreen mode

Let's take a look at staging.json:

{
  "baseUrl": "http://localhost:3000",
  "env": {
    "env": "staging",
    "apiUrl": "https://staging-api.com/api/v1",
  }
}
Enter fullscreen mode Exit fullscreen mode

And production.json:

{
  "baseUrl": "http://localhost:3000",
  "env": {
    "env": "production",
    "apiUrl": "https://api.com/api/v1",
  }
}
Enter fullscreen mode Exit fullscreen mode

(!)Make sure you store your env variables inside env object

Then update cypress scripts in package.json to make sure you run cypress with needed config for each env:

"scripts": {
 "cypress:run:staging": "cypress run --env configFile=staging",
 "test:e2e:staging:run": "start-server-and-test 'npm run start' http://localhost:3000 'npm run cypress:run:staging'",

 "cypress:run:production": "cypress run --env configFile=production",
 "test:e2e:production:run": "start-server-and-test 'npm run start' http://localhost:3000 'npm run cypress:run:production'",
}

// same approach could be used for "cypress open" command.
Enter fullscreen mode Exit fullscreen mode

"start-server-and-test" module runs your app and right after that triggers cypress tests.

Then update src/cypress/plugins/index.js with the following code:

const fs = require('fs')
const path = require('path')

function getConfigurationByFile(fileName) {
  const pathToConfigFile = path.resolve(__dirname, `../config/${fileName}.json`);
  let rawData;
  try {
    rawData = fs.readFileSync(pathToConfigFile);
  } catch (e) {
    console.error(e);
  }
  return JSON.parse(rawData);
}

module.exports = (on, config) => {
  // `on` is used to hook into various events Cypress emits
  // `config` is the resolved Cypress config

  // this value comes from *cypress run --env configFile=staging*
  const configFile = getConfigurationByFile(config.env.configFile || 'test');

  return { ...config, ...configFile };
};
Enter fullscreen mode Exit fullscreen mode

Great! So now when we have our cypress up and running with needed env config, we can use values from that configs in our tests..

If you've done everything correct, then you are able to extract the variables by doing the following:

const { apiUrl, env } = Cypress.env();
// to extract baseUrl variable you should use Cypress.config()
// const { baseUrl } = Cypress.config();
Enter fullscreen mode Exit fullscreen mode

 

Change fixture's values on the fly based on env

Basically fixtures is being used when you need to mock an API response, which is not recommended though
But when you have a few environments sooner or later you will face an issue when the same requests return the same data for each env except a few values(e.g. id). And you might not want to duplicate the whole fixture.

In this case all you need to do is to extract a fixture and your env variable; then update needed value on the fly within a test case:

describe('it should test smth', function() {
  beforeEach(() => {
    // user is a env variable
    const { user: userEnv } = Cypress.env();

    cy.fixture('user.json').then(user => {
      user.id = userEnv.id; // updating user id
      // use updated fixture here (e.g. `cy.intercept`)
    });
  });
});
Enter fullscreen mode Exit fullscreen mode

(!)If you use beforeEach, make sure you wrap it in describe, so it won't affect other tests.

Here is the link to fixture docs

 

Mock API response globally

To stub network request globally, you should open src/cypress/support/index.js file and add the following code:

beforeEach(() => {
  cy.intercept({ url: `${apiUrl}/profile*`, middleware: true }, req => {
    req.reply({
      fixture: 'getProfile.json',
    });
});
Enter fullscreen mode Exit fullscreen mode

Here is the link to itercept docs

 

Custom commands

Custom commands in Cypress prevent you from having to add boilerplate code to your tests.
Take a look at this file:

 // you can turn this piece of code
 it('should fill in discount form', function() {
    cy.get('input[name="email"]').type('test@test.com');
    cy.get('input[name="phone"]').type('1231231212');
    cy.get('div[role="checkbox"]').click({ force: true });
    cy.findByText(/Save/i).click({ force: true });
    // ...rest of the test
  });

// into a single line
it('should fill in discount form', function() {
 cy.fillDiscountForm();
 // ...rest of the test
});
Enter fullscreen mode Exit fullscreen mode

To create cy.fillDiscountForm() command you should go over to the file at src/cypress/support/commands.js and create a custom command there:

Cypress.Commands.add('fillDiscountForm', function() {
  cy.get('input[name="email"]').type('test@test.com');
  cy.get('input[name="phone"]').type('1231231212');
  cy.get('div[role="checkbox"]').click({ force: true });
  cy.findByText(/Save/i).click({ force: true });
});
Enter fullscreen mode Exit fullscreen mode

That's it! Now you can use cy.fillDiscountForm() in any test.

Here is the link to custom commands

 

Waiting on a request

Before your app displays any data, it will probably get it from the server. What if you have poor internet connection and all your tests are failing due to unfinished API requests, and lack of the data to display? In this case, and probably every time you make an API call, you should wait (cy.wait) for the API call to finish before doing any assertions.

it('should fill in discount form', function() {
  cy.intercept(`${apiUrl}/settings`).as('getSettings');
  cy.visit(`/settings-page`);
  // once a request to get settings responds, 'cy.wait' will resolve
  cy.wait('@getSettings');
  // rest of the test
  // cy.contains(/edit settings/i).click({ force: true });
});
Enter fullscreen mode Exit fullscreen mode

All we need to do is to register the intercept before visiting the settings page. Once we visit the settings page, it will trigger GET ${apiUrl}/settings request, and cypress will wait till it finishes and only after that will continue the testing.

Furthermore, if the API call fails for some reason, then Cypress will display an error and it will be much easier to debug.

Here is the link to wait docs

 


Cover image by Tianyi Ma

Top comments (3)

Collapse
 
priteshusadadiya profile image
Pritesh Usadadiya

[[Pingback]]

Curated as a part of #18th Issue of Software Testing Notes newsletter.

softwaretestingnotes.substack.com/...

Collapse
 
only4arunkumar profile image
only4arunkumar

Nice , thanks for making it precise . good work

Collapse
 
ryabinin profile image
Vlad R

thanks for the feedback!