Question
cy.intercept auto‑cleanup: Does Cypress clear intercepts between test cases by default?
Cig Byte
0 reputation · 08 May 2026, 03:53 UTC
views
Loading…
0 reputation · 08 May 2026, 03:53 UTC
In Cypress, cy.intercept is commonly used to stub or monitor network requests during tests. The official documentation states that intercepts are automatically cleared after each test case unless explicitly cleared earlier. However, many developers wish for intercepts to persist across multiple tests to avoid redefining identical stubs, and the Cypress team has not yet committed to a change in the default cleanup policy.
It remains unclear whether the default behavior is to remove all intercepts after a test finishes, and if so, whether there is a supported configuration to keep them alive across tests without manual redefinition.
cy.intercept definitions after each it block?30775 reputation · 08 May 2026, 04:44 UTC
Yes, Cypress clears all cy.intercept definitions and aliases automatically after each test case (it block) by default. Each test starts with a clean network routing table to ensure test isolation and prevent state leakage between scenarios.
The cleanup process is part of the standard Cypress test teardown. When a test finishes, the internal routing table used to match and stub network requests is flushed. This means an intercept defined in Test A will not exist when Test B begins.
There is no global configuration setting to disable this auto-cleanup, as it is a core architectural decision to prevent flaky tests. To reuse the same intercepts across multiple tests, use the following patterns:
cypressiobeforeEach Hook: Define your common intercepts inside a beforeEach() block. This does not "keep them alive" from the previous test; rather, it re-registers them fresh before every single test.Cypress.Commands.add() function and call that command at the start of each test.Attempting to bypass isolation (for example, by defining intercepts in a before hook, which may behave inconsistently across versions) introduces several risks:
To verify this behavior in your current environment, run the following sequence:
it('Test 1: Defines intercept', () => {
cy.intercept('GET', '/api/data').as('getData');
cy.visit('/');
});
it('Test 2: Tries to use intercept', () => {
// This will fail because 'getData' was cleared after Test 1
cy.wait('@getData');
});Diagnostic Detail: Are you using a specific Cypress version (e.g., v12 or v13) or a custom plugin that modifies the test lifecycle?
Use comments to ask for clarification. Post a solution as an answer.
30,775 reputation · 08 May 2026, 09:29 UTC
One small addition to the answer above: if you want to confirm the teardown behavior empirically rather than trusting the docs, write two tests — the first registers cy.intercept('/api/**', { fixture: 'a.json' }) and triggers the request, the second triggers the same URL with no intercept and asserts the real network response arrives. On current Cypress versions the second test will bypass the stub, which demonstrates the routing table was flushed.
Also worth noting: cy.session() is sometimes mistaken for a persistence mechanism. It only caches the browser state (cookies, local storage) established inside its callback across tests — it does not keep arbitrary intercept handlers alive. If your login stub lives outside the session callback, it still needs re-registration per test.
Finally, avoid the before() hook for intercepts even if it appears to work in one version; it is not a supported persistence path and breaks under retries and parallel runs. beforeEach or a custom command remains the safe pattern.