With Cypress testIsolation on, what is reset between tests and what survives?

## What `testIsolation` is `testIsolation` is a Cypress configuration option, **`true` by default**, that decides whether the runner puts the browser back into a clean context before each test. As of Cypress 16 it applies to end-to-end testing only: component testing always resets and rejects the option outright. It is the switch that turns "each test starts from nothing" from a discipline you have to enforce into something the runner does for you. It is worth separating two resets that people blur together. - **The always-on slate.** Regardless of `testIsolation`, Cypress restores and clears its own per-test state before every test: aliases, `cy.clock()` mocks, `cy.intercept()` routes, `cy.spy()` and `cy.stub()` doubles, and any `cy.viewport()` change. - **The browser context**, which is what `testIsolation` governs. ## What the browser-context reset clears With `testIsolation: true`, before each test Cypress: - clears the DOM by navigating the application frame to **`about:blank`**; - clears **cookies** in all domains; - clears **`localStorage`** in all domains; - clears **`sessionStorage`** in all domains. The practical consequence is that each test must call `cy.visit()` again and re-establish whatever the catalogue page needs. A borrow flow cannot be spread over three `it()` blocks that each pick up where the last one stopped, because the page is gone by the time the second one starts. ## What survives — and the one to remember Cookies, `localStorage` and `sessionStorage` are the **only** storage mechanisms Cypress clears. Everything else in the browser persists for the life of the browser, whether isolation is on or off, and in both testing types. The one that bites is **IndexedDB**. A catalogue app that keeps an offline copy of search results, a borrowing basket, or a client-side database still has all of it in the next test. Libraries that use IndexedDB under the hood — offline caches, sync engines, client-side stores — leak silently, because nothing in the Command Log says so. The same limit applies to a cached session: a session saves and restores cookies and web storage only, so IndexedDB is neither captured with one nor cleared when one is restored. | | `testIsolation: true` (default) | `testIsolation: false` | |---|---|---| | Page | navigated to `about:blank` | left exactly as the last test left it | | Cookies, `localStorage`, `sessionStorage` | cleared in all domains | not touched | | IndexedDB and other storage | **not cleared** | **not cleared** | | Aliases, clock, intercepts, spies, stubs, viewport | reset | reset | | Where you may set it | root config or a `describe` block | a `describe` block | ## Clearing what Cypress will not If a test depends on IndexedDB being empty, empty it yourself, in a `beforeEach` and after a `cy.visit()` so a `window` exists: 1. Get the application window with `cy.window()`. 2. Call the browser's `indexedDB.deleteDatabase()` for each database your app uses. 3. Wrap the request in a `Cypress.Promise` and resolve on `onsuccess`, `onerror` **and** `onblocked`, so a missing or blocked database cannot hang the test. If you do not know the names ahead of time you can enumerate them with the browser's `indexedDB.databases()` in Chromium-based browsers and WebKit; Firefox does not implement it, so name each database explicitly if you run there. ## What isolation costs, and why it is still the default Re-visiting and re-seeding per test is real time, and that cost is the whole argument people make for switching isolation off. The counter-argument is that the alternative is a suite whose tests only pass in one order — reorder them, run one alone, or let a retry re-enter the block, and the result changes. Cypress ships the reset on by default precisely so that a green test means the same thing whether it ran first or fourteenth. The cheap ways to pay less without giving up the reset are: - seed catalogue data programmatically in a `before` or `beforeEach` — an API call or a `cy.task()` is far cheaper than driving the UI to build state; - re-set a known cookie you control with `cy.setCookie()` in `beforeEach` rather than clicking through a banner in every test; - restore an expensive authenticated context from a cached session instead of repeating a sign-in. Two details are worth carrying into an interview because they are where the model breaks down in practice. First, the reset is **per test, not per spec**: the last test of a run is left standing so you can keep using the catalogue app where it stopped, which is why open mode does not blank the page after the final test. Second, the reset is a **browser** operation and knows nothing about your server — records the suite created through the API are exactly where the previous test left them, and no `testIsolation` setting will undo them.