Mocking in Cypress: When to Use It and When Not to

Introduction

Automated testing plays a crucial role in ensuring software quality, and Cypress has become a popular tool for UI and API testing. One of its powerful features is mocking, which allows developers to simulate API responses instead of making real network requests. But is mocking always the right choice? In this blog, we will explore how Cypress mocking works, its advantages, and situations where it might not be the best approach.

What is Mocking in Cypress?

Mocking in Cypress refers to intercepting network requests and returning predefined responses instead of calling the actual backend API. This is done using cy.intercept(), which allows you to control API responses within tests.

Example: Mocking a User API Response

Let’s assume our application fetches user details from an API endpoint:

GET /api/users/12345

Instead of sending a real request, we can mock this response in Cypress:

describe("Mocking API in Cypress", () => {
  it("should display mocked user data", () => {
    cy.intercept("GET", "/api/users/12345", {
      statusCode: 200,
      body: {
        id: "12345",
        userName: "mockedUser",
        email: "mocked@example.com",
        roles: ["mocked-admin"]
      }
    }).as("mockedUserRequest");

    cy.visit("/user-profile");
    cy.wait("@mockedUserRequest");

    cy.contains("mockedUser").should("be.visible");
    cy.contains("mocked@example.com").should("be.visible");
    cy.contains("mocked-admin").should("be.visible");
  });
});

This test ensures the UI correctly displays user details, even though no real request was made to the backend.

When Should You Use Mocking?

Mocking API requests in Cypress can be useful in several scenarios:

✅ Faster Tests: Mocked responses eliminate network delays, making tests run significantly faster.

✅ Stable and Reliable: Tests won’t fail due to network issues, server downtime, or API rate limits.

✅ Control Over Responses: You can simulate different scenarios such as success, failure (500 Internal Server Error), or empty data (204 No Content).

✅ Isolate Frontend Logic: Focus on testing UI behavior without depending on backend changes.

Example: Simulating an API Failure

cy.intercept("GET", "/api/users/12345", {
  statusCode: 500,
  body: { error: "Internal Server Error" }
}).as("mockedFailure");

This helps ensure the UI handles API failures gracefully.

When Should You Avoid Mocking?

While mocking can be beneficial, it’s not always the right approach. Here are situations where real API calls are better:

❌ When Testing the Backend Itself — Mocking prevents requests from reaching the actual backend, meaning you won’t be able to verify if the API is working correctly.

❌ When Validating End-to-End (E2E) Flows — If your test involves multiple systems interacting (e.g., login, authentication, database updates), mocking may give a false sense of reliability.

❌ When Testing Adaptive Behaviors — If the application’s behavior depends on real API responses (e.g., user role-based UI changes), mocking might not reflect real-world conditions.

Example: Adaptive Authentication Without Mocking

Instead of mocking login requests, allow the real authentication process to happen and validate expected UI behavior:

describe("Real Login Test", () => {
  it("should trigger MFA for certain users", () => {
    cy.visit("/login");
    cy.get("#username").type("testUser");
    cy.get("#password").type("Test@123");
    cy.get("button[type=submit]").click();
    
    // Check if MFA is triggered
    cy.url().should("include", "mfa");
    cy.get("#otp").should("be.visible");
  });
});

This approach ensures that the actual authentication logic is tested instead of just assuming the UI behaves correctly.

Balancing Mocking and Real Requests

To get the best of both worlds, follow these guidelines:

• Mock APIs when testing UI behavior (e.g., displaying user details, handling error messages).
• Use real API requests for end-to-end flows (e.g., login, data persistence, authentication flows).
• Mix both approaches when needed, such as allowing login calls but mocking secondary requests like user role fetching.

Conclusion

Mocking in Cypress is a powerful tool for speeding up tests and isolating frontend logic, but it’s not always the right choice. When testing backend behavior, end-to-end workflows, or dynamic adaptive logic, real API calls are necessary. By carefully deciding when to mock and when to use real requests, you can create reliable, effective, and meaningful test suites.

Do you use mocking in your Cypress tests? When do you find it most useful? Let’s discuss in the comments!