Between two Cypress component tests, what is torn down automatically and what survives?

## What Cypress resets for you Component testing has a fixed isolation policy. Before each test, Cypress resets the browser context by: - **unmounting the rendered component under test** - **clearing cookies** in all domains - **clearing `localStorage`** in all domains - **clearing `sessionStorage`** in all domains That is the complete list, and it is not adjustable. `testIsolation` is an end-to-end configuration option; component testing does not support configuring isolation behaviour at all, so there is no supported way to carry a mounted component or a cookie from one test into the next. ## Where the unmount actually comes from It is worth knowing that the unmount is not core runner behaviour bolted onto every spec. It arrives with the adapter. Importing `cypress/react`, `cypress/vue`, `cypress/angular` or `cypress/svelte` registers a cleanup callback as a side effect, and because you import the adapter in `cypress/support/component.js` to register `cy.mount`, that registration happens for every component spec. Each adapter's cleanup is framework-appropriate: React unmounts the root it created, Angular tears down and resets its `TestBed`, Vue unmounts the wrapper and removes the node it appended, Svelte calls Svelte's own `unmount`. There are two moments it runs: 1. **As a test ends**, through the registered hook - which is why you never write teardown in a component spec. 2. **At the start of a mount**, so calling `cy.mount` twice inside one test discards the first tree instead of leaving two `Toast` components stacked in the root element. A consequence worth internalising: a hand-rolled mount that renders a component without going through an adapter gets neither. Teardown is a property of the adapter, not of the runner. ## What survives, and why it bites | Survives between tests | Why the reset misses it | |---|---| | IndexedDB | Cookies and web storage are the only storage mechanisms Cypress clears, in both testing types | | Module-level state in your bundle | Each spec file's imports evaluate once; a singleton keeps whatever the last test put in it | | Listeners a component added to `document` or `window` | The component's tree is removed, but a listener attached outside it is not | | Real timers and intervals still pending | Nothing cancels a `setInterval` a component started and did not clear on unmount | | Styles the component injected into `<head>` | Injected outside the root element, so removing the root leaves them behind | In a design system this list is not academic. A `toastQueue` module that keeps pending messages, a theme registry memoised at import time, a `DataGrid` that registers a global keydown handler for its shortcuts - each is a legitimate design and each leaks between tests in the same spec file. ## Diagnosing a leak The signature is a suite that is green one test at a time and red as a whole, with failures that move when the order changes. 1. **Run the failing test alone.** If it passes, the state came from a neighbour rather than from the component. 2. **Look at what the spec imports, not what it mounts.** The leak is almost always at module scope in an import, because that is the one region the reset does not reach. 3. **Check for handlers outside the component's own tree** - anything the component adds to `document`, `window` or a shared bus in an effect and does not remove on teardown. 4. **Fix it in the component first, if you can.** A component that leaks a listener between tests leaks it between route changes in production too; the failing test is describing a real defect, not a harness gap. 5. **Otherwise reset explicitly** in a Mocha `beforeEach` in the spec, or - if every component in the library needs it - in the support file next to the `cy.mount` registration. ## Two things people get wrong - **"Cypress clears everything, so my test is isolated."** It clears four things. Everything your own code owns is your responsibility. - **"I should call unmount myself to be safe."** There is no `unmount` export to call - it was removed from `cypress/react` several majors ago - and calling one would be redundant with the adapter's own cleanup. The right lever is a `beforeEach` that resets *your* state, not the framework's. ## The judgement underneath Automatic teardown is a convenience, not a guarantee of isolation, and treating it as a guarantee is how suites become order-dependent without anyone deciding to make them so. The useful team rule is narrow: module-level mutable state in a design-system package is allowed only where something owns resetting it, and that owner is named in the same file. Then a leak is a review comment rather than a week of chasing a flaky suite.