cypress intercept vs stub: when to use each

TL;DR

Use cy.intercept() to stub network responses the app fetches; use cy.stub() for direct function spies. Intercept tests the real request path; stub tests units in isolation.

Error

(Not an error; a technique choice. The confusion: both are called "stubbing".)

Steps

1. If the code under test makes a real HTTP request, use cy.intercept() with a fixture or inline body. Expected: the app's fetch path exercised.
2. If testing a callback or method directly, use cy.stub() / sinon.stub(). Expected: unit-level control.
3. Do not stub what you can intercept: intercept keeps more of the real stack. Expected: higher-fidelity tests.
4. Do not intercept what should be a contract test: over-mocked e2e hides backend drift. Expected: a few unmocked paths remain.
5. Document which tests mock what in the test name or comment. Expected: future readers know the fidelity.

When to use

• Deciding mock strategy for a test.
• Reviewing over-mocked suites.

When not to use

• You need full-stack confidence (use real backend for some tests).
• Playwright (use page.route).

Tool compatibility

• Cypress 10 through 14; cy.intercept, sinon stubs.

Variant phrasings

Cypress stub API response

Usually means intercept; use the network-level tool.

cy.intercept vs cy.stub

The comparison; network vs function.

Why it happens

Both fake dependencies but at different layers. Choosing the wrong layer either over-isolates or under-controls.

Edge cases

• cy.intercept() cannot stub non-network calls; that is what cy.stub() is for.
• Stubbing window.fetch directly fights with intercept; pick one.
• GraphQL needs body-based matching in intercept.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bRps9T4kOgifPIp7jV71nQ