02 / 05

How do we Stub a Response using cy.intercept() for network requests?

cy.intercept() lets you:​
  1. 1

    Cypress intercepts the real network call and replaces the response.

  2. 2

    The request will get a mocked 200 OK response with your custom JSON data.

  3. 3

    as('mockedUsers') allows you to wait or assert on it later.

  4. 4

    We can stub using fixtures as well.

The backend isn't ready yet — or you want your test to be consistent and not depend on real data from the server.
Difficulty: 5/10
Topics: cy.intercept, response stubbing, network mocking

Scenario Questions

0-2 years experience
  1. 1

    We have a login page that POSTs to /api/login. How would you write a Cypress test that stubs the response to return a successful token?

  2. 2

    If the backend endpoint /api/products returns a 500 error, how can you use cy.intercept to simulate that error and assert the error banner appears?

2-5 years experience
  1. 1

    Your team added pagination to the orders table, but the test that stubs the first page now fails intermittently. Walk me through how you'd debug the cy.intercept stub and what changes you might make.

  2. 2

    You need to stub multiple calls to /api/user/profile with different responses based on query parameters. How would you configure cy.intercept to handle this within a single test?

5-8 years experience
  1. 1

    In a large test suite we see a performance hit because each test loads large JSON fixtures via cy.intercept. What strategies would you employ to reduce the overhead while keeping stubs reliable?

  2. 2

    Discuss how you would design a reusable Cypress utility that centralizes all API stubs, supports versioned contracts, and can be shared across multiple feature teams.

8+ years experience
  1. 1

    Our organization is moving from contract testing with Pact to Cypress stubbing for end‑to‑end tests. What architectural considerations and migration plan would you propose to ensure consistency and avoid duplicated mock definitions?

  2. 2

    How would you set up a cross‑team governance model for managing cy.intercept stubs, versioning, and deprecation of legacy API mocks in a microservices environment?

Follow-up Questions

  • How would you verify that the UI reacts correctly to the stubbed data?
  • What changes would you make if the API shape evolves over time?
  • Can you describe how you would keep stub definitions DRY across many tests?