testIsolation default true in Cypress 12 changes cross-test state handling

Direct Answer

Use a lightweight validate callback that performs a single cheap assertion—such as verifying a session cookie exists and is unexpired, or making one authenticated API request with a short timeout. Omit validate only when sessions are short-lived test fixtures created per run, the backend never revokes sessions mid-run, and a stale session would cause an obvious, fast test failure rather than a misleading pass. Treat cache invalidation as a contract between your test setup and the backend: if the backend can invalidate sessions independently of your test code, you need validation; if sessions are fully controlled by the test run, you can skip it.

Confirmed Behavior (Cypress 12+)

• testIsolation: true (default) clears cookies, localStorage, sessionStorage, and the page before each it block. State from before/beforeEach hooks no longer persists across tests.
• cy.session(id, setup) caches the browser state after setup runs once. The cache key is derived from the setup function's source code; editing the function invalidates the cache automatically.
• The cache captures only client-side state. Server-side revocation, token expiry, or permission changes are invisible to the cache key.
• The optional validate callback runs after a cached session is restored. If it throws or an assertion fails, Cypress discards the cache entry and re-runs setup.

Recommended Validation Strategy

1. Pick a cheap, side-effect-free check. Examples:
   • Assert the session cookie exists and its expiry is in the future: cy.getCookie('sessionid').should('exist').and('have.property', 'expiry').and('be.gt', Date.now())
   • Make one lightweight authenticated request (e.g., cy.request('/api/me')) with a short timeout (2–5 s) and assert a 200 response.
2. Avoid full UI login flows in validate; they erase the time savings of caching.
3. Keep validation deterministic. The callback should not mutate server state or depend on flaky network conditions.

When Omitting validate Is Acceptable

All three conditions must hold:

• Sessions are created as test fixtures for the current run only (e.g., a test user seeded before the suite).
• The backend does not revoke or expire sessions during the test run (no background cleanup jobs, no admin revocation, short TTL aligned with suite duration).
• A stale session would cause an immediate, obvious failure (e.g., a 401 on the first request in the test) rather than a false pass or cryptic error.

If any condition is uncertain, add a minimal validate.

Reasoning About Cache Invalidation

Separate code-driven invalidation (handled automatically by Cypress when the setup function changes) from external invalidation (server-side revocation, expiry, config changes). Ask:

• Can the backend invalidate a session without a deploy? If yes, you need validate.
• What is the cost of a false pass vs. the overhead of validation? A 200 ms API check per test is usually worth avoiding hours of debugging flaky suites.
• Does your CI run tests in parallel? Parallel runs may share a cached session across processes; cacheAcrossSpecs and process isolation affect this.

Verification Steps

1. Write a spec with two tests sharing a cy.session() login. Run with testIsolation: true and confirm the second test restores the session without re-running setup (check the Cypress command log).
2. Simulate external invalidation (clear the server session or expire the token between tests) and confirm validate triggers a setup re-run.
3. Time the suite with and without the validate callback to ensure overhead fits your CI budget.

One Diagnostic Detail Needed

What is your backend's session invalidation model? (e.g., JWT with short TTL, opaque tokens revoked on logout, server-side session store with admin revocation). This determines whether validate can be a cookie check or must hit an API endpoint.