Setting up Cypress for a React application

I took the lead on setting up Cypress for end-to-end testing in a React + Vite + TypeScript application. The app is a shipping logistics portal and the test suite now covers 31 test files across the application. Here is how I approached the setup.

Installing Cypress

pnpm add -D cypress

Then add scripts to package.json:

"cy:open": "cypress open",
"cy:open:frontend": "cypress open --env CYPRESS_BASE=frontend",
"cy:open:localhost": "cypress open --env CYPRESS_BASE=localhost",
"cy:run": "cypress run",
"cy:run:frontend": "cypress run --env CYPRESS_BASE=frontend"

This gives us different commands for different environments - more on that below.

Multi-environment configuration

One of the first things I wanted to get right was being able to run the same tests against multiple environments. In cypress.config.ts I set up a function that returns the correct base URL and API URL depending on an environment variable:

import { defineConfig } from "cypress";

function getBaseUrls(env: string) {
  switch (env) {
    case "frontend":
      return {
        baseUrl: "https://frontend.example.se:3000/",
        apiUrl: "https://frontend.api.example.se/",
      };
    case "localhost":
      return {
        baseUrl: "https://localhost:3000/",
        apiUrl: "https://localhost:44367/",
      };
    default:
      return {
        baseUrl: "http://dev.portal.example.se/",
        apiUrl: "https://dev.api.example.se/",
      };
  }
}

const env = process.env.CYPRESS_BASE || "dev";
const urls = getBaseUrls(env);

export default defineConfig({
  projectId: "your-project-id",
  e2e: {
    baseUrl: urls.baseUrl,
    setupNodeEvents(on, config) {
      config.env.apiUrl = urls.apiUrl;
      return config;
    },
  },
  env: {
    CYPRESS_BASE: env,
  },
  defaultCommandTimeout: 40000,
  requestTimeout: 40000,
  retries: 2,
  experimentalStudio: true,
  experimentalMemoryManagement: true,
  experimentalRunAllSpecs: true,
});

Now running pnpm cy:open opens Cypress against the dev environment, while pnpm cy:open:frontend targets the frontend staging environment.

Custom commands

I created reusable custom commands in cypress/support/commands.ts to avoid repeating common actions across tests.

Cypress.Commands.add("loginAsSuperAdmin", (visit: string = "/") => {
  cy.visit(visit);
  cy.get('[data-cy="username"]').type("[email protected]");
  cy.get('[data-cy="password"]').type("testpassword", { log: false });
  cy.get('[data-cy="login-button"]').click();
});

Cypress.Commands.add("loginAsSupplier", (visit: string = "/") => {
  cy.visit(visit);
  cy.get('[data-cy="username"]').type("[email protected]");
  cy.get('[data-cy="password"]').type("supplierpass", { log: false });
  cy.get('[data-cy="login-button"]').click();
});

Test data reset

Cypress.Commands.add("resetTests", () => {
  cy.request("GET", Cypress.env("apiUrl") + "api/v2/test/reset-tests").then(
    (response) => {
      cy.log("Reset status: " + response.status);
    }
  );
});

This calls an API endpoint to reset the test data before test runs, keeping things isolated.

Reusable UI interactions

Cypress.Commands.add(
  "selectLocation",
  (type: string, locationName: string, locationId: string) => {
    cy.get(`[data-cy="${type}Location"] input`).type(locationName);
    cy.wait(2000);
    cy.get(`[data-cy="location-${locationId}"]`).click();
  }
);

Don’t forget to add type definitions in commands.d.ts so TypeScript is happy:

declare namespace Cypress {
  interface Chainable {
    loginAsSuperAdmin(visit?: string): Chainable<void>;
    loginAsSupplier(visit?: string): Chainable<void>;
    resetTests(): Chainable<void>;
    selectLocation(
      type: string,
      locationName: string,
      locationId: string
    ): Chainable<void>;
  }
}

Using data-cy attributes

We use data-cy attributes on React components to make selectors resilient to styling and markup changes:

// In the React component
<TextField data-cy="username" ... />

// In the test
cy.get('[data-cy="username"]').type("[email protected]");

This is one of Cypress best practices and saves a lot of headaches when the UI is redesigned.

API interception

One of the most useful Cypress features for us is cy.intercept(). We use it heavily to wait for API calls and assert on responses:

cy.intercept("POST", "/api/v2/search?query=&key=dashboard").as(
  "dashboardRequest"
);

// trigger the action that makes the API call
cy.get('[data-cy="search-button"]').click();

cy.wait("@dashboardRequest").then((interception) => {
  expect(interception.response?.statusCode).to.equal(200);
});

This is much more reliable than using fixed cy.wait(3000) calls since the test waits for the actual network request to complete.

CI integration with GitHub Actions

I set up a GitHub Actions workflow that runs the Cypress suite on every push to develop:

name: Cypress Tests
on:
  push:
    branches:
      - develop

jobs:
  cypress-run:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: true

      - name: Setup pnpm
        uses: pnpm/action-setup@v2

      - name: Install dependencies
        run: pnpm install --no-frozen-lockfile

      - name: Cypress run
        uses: cypress-io/github-action@v6
        with:
          record: true
        env:
          CYPRESS_RECORD_KEY: $

We also connected it to Cypress Cloud for test recording, which gives us screenshots and video on failures plus historical trends.

Lessons learned

Start with data-cy attributes early. Adding them retroactively to a large codebase takes time.
Use cy.intercept() over cy.wait(). Waiting for network requests is more reliable than arbitrary timeouts.
Multi-environment support from day one. Being able to run the same tests against dev, staging and localhost has been very useful.
Keep custom commands small and focused. A few well-designed commands go a long way.
Enable retries. Setting retries: 2 in the config helps with flaky tests while you work on making them more stable.