Cypress Test Runner and Browser Under Test: cy.intercept stub timing vs assertion retry

Question

Cypress runs tests inside a real browser and proxies network traffic between the test runner process and the application under test. The integration boundary is relevant when verification of UI state depends on network interception via cy.intercept.

The goal is to understand how stubbing, delaying, or asserting on network calls interacts with Cypress assertion retry behavior. Assertions automatically retry until timeout, which changes verification of dynamic UI compared to one-shot checks. Backup creation, restoration, or data recovery are not Cypress capabilities and are out of scope for this integration.

Uncertainty remains about the ordering guarantees between intercept registration and the first request, and how retry interacts with intercept lifecycle across e2e and component testing modes. Version-sensitive changes to interception APIs add further ambiguity.

Does an assertion that depends on a stubbed response wait for the intercept to be registered, or can it succeed on a prior real response? Under what conditions does automatic retry allow a test to pass with stale network data when intercept timing shifts? Is retry behavior consistent between e2e and component testing for intercepted requests?

Tasadduq Burney · Answer

Likely explanationWhen cy.intercept is registered before the application makes a network request, the intercept blocks or redirects that request and serves the stubbed response. Subsequent Cypress assertions (for example cy.should) retry until their 4-second timeout, re-evaluating UI state after each network response. If the intercept is registered after the first request passes through the Cypress proxy, that request reaches the real server and the assertion may succeed on that real response before the stub ever takes effect. In e2e testing, the intercept operates at the browser-proxy layer and only blocks requests that arrive after registration. In component testing, intercepts are polyfills/mocks that do not block the original request; assertion retry loops are generally absent, so timing guarantees differ fundamentally.Confirmed factsCypress assertion retry (cy.should, cy.wait) re-runs the assertion after each network response until the timeout expires.An intercept alias must be registered before the request passes through the Cypress proxy for the intercept to affect that request.Cypress 12 introduced component-testing intercept support; pre-v12 intercepts are effective only in e2e mode.Version-specific API changes (response-shape options, delay handling) can alter blocking and retry semantics.Steps to verify for this casePlace cy.intercept before the app makes the request (typically before cy.visit or component mount).Check the Cypress Command Log to confirm the intercept alias is active before the request appears.Use cy.wait(alias) before the assertion; observe that retries only occur after the intercepted response is received, confirming the intercept was registered in time.If using component testing, inspect the mocked fetch/XHR calls directly, as blocking and retry behavior differ from e2e mode.Missing diagnostic detailTo determine whether assertion retry will respect the intercept, confirm the Cypress major version you are using. Version 12+ provides component-testing intercept blocking; earlier versions do not.

Cypress Test Runner and Browser Under Test: cy.intercept stub timing vs assertion retry

1 answer

Likely explanation

Confirmed facts

Steps to verify for this case

Missing diagnostic detail

Your perspective belongs here.

0 question comments