Introduction

Why use Cypress?

• Cypress allows us to write the following tests, while giving developers access to its interactive GUI

  • End-to-end tests

  • Component tests

  • Integration tests

  • Unit tests

• Grab a coffee while you go through the features of Cypress.

Setup and Installation

Installation Steps

Dev Tests

While on development environment, check if you have the following file setup in the root folder of your local application (refer to the below image)

Common config changes

Put such changes like the viewport height/width settings, etc. directly in the defineConfig object.

E2E testing config changes

Put changes specific to E2E testing the e2e object. Following are the current e2e configs:

e2e: {
    baseUrl: 'http://localhost:3000', // base url for e2e testing
    excludeSpecPattern: '**/examples/*', // used to exclude tests whose names are filtered by the regex
    screenshotOnRunFailure: false, // if true a screenshot folder will be included with all the screen snippets when your tests fail
  },

Component testing config changes

Put changes specific to E2E testing the e2e object. Following are the current e2e configs:

component: {
    devServer: {
      framework: 'create-react-app',
      bundler: 'webpack',
    },
    screenshotOnRunFailure: false,
    // Defines environment variables for the component tests
    env: {
      REACT_APP_MAPBOX_API_KEY: 'pk.eyJ1IjoibWlrYWhwaW5lZ2FyIiwiYSI6ImNseHZ2NndjZDJrejMycXB4dWtlamo2eWYifQ.29yeP8CgZpO98jyzxYxU4Q',
    },
  },

Writing Tests

Testing Structure

Use the following structure for your test (spec) files:

• Describe Blocks: Group related tests.

• It Blocks: Define individual test cases.

• Assertions: Validate expected outcomes.

For example,

describe('My React App', () => {
  it('should display the correct title', () => {
    cy.visit('/');
    cy.title().should('include', 'React App');
  });
});

Selectors and Best Practices

• Use Data Attributes: Prefer data attributes (data-cy) for selecting elements.

• Avoid Complex Selectors: Use simple selectors to avoid brittle tests.

Custom Cypress Commands

Use the cypress/support/< e2e/component >.js file to write custom commands for either e2e or component testing.
For example to avoid writing repetitive code to assert an element by id use the custom created command cy.assertByTestId

// code for adding a custom Cypress command
// @Params: [test-id]: string
// usecase: cy.assertByTestId("<test-id>");
// result: gives assertion for element existance
 
Cypress.Commands.add('assertByTestId', (testId) => {
  cy.get(`[data-cy=${testId}]`).should('exist');
});

Running Tests

Debugging and Troubleshooting

Best Practices

• Keep Tests Independent: Ensure each test runs in isolation.

• Use Fixtures for Test Data: Load static data from files. Avoid making API calls from tests, as this will additional load on the servers. Use cy.intercept to intercept any type of HTTP call and send back dummy data.

• Clean Up: Use hooks like beforeEach and afterEach to set up and tear down test states.

• Write Descriptive Tests: Use clear and descriptive names for test cases and assertions. Begin all test descriptions with should.

• Custom Commands: For repeated DOM queries, use aliases to make tests more readable.

• BeforeEach: Use before each for all the repetitive commands within a describe block that is common to all the it blocks

• Only assertions in It Blocks: Goal is to keep the It blocks as lean as possible, hence, avoid writing anything other than state management blocks and assertions in the It Blocks. Use the describe block to write all the component mounting and data initialization logic.

References

• Cypress Documentation