In a Cypress component test, how do you fast-forward a toast's auto-dismiss timer?

A toast that dismisses itself after five seconds is trivially testable and ruinously slow to test honestly. Twenty such assertions is a hundred seconds of a suite doing nothing. Cypress's answer is to **fake the clock** rather than wait on it: replace the browser's timer functions with controllable stand-ins, then move time forward by hand. ## What `cy.clock()` replaces By default `cy.clock()` overrides five globals on the top window: - `setTimeout` and `clearTimeout` - `setInterval` and `clearInterval` - `Date` Two limits are worth stating up front. The fake applies to the **top window only** — it does not reach into an embedded iframe — and it only affects timers scheduled *after* it is installed. Anything already scheduled against the real `setTimeout` keeps running on real time, invisible to `cy.tick()`. ## Why the clock goes in before the mount This is the ordering trap, and it is specific to component tests. Mounting a component renders it but does not touch the page or the window object, which means installing the clock first is both safe and correct: ```js cy.clock() cy.mount(<Toast duration={5000} onDismiss={cy.spy().as('onDismiss')} />) cy.tick(5000) cy.get('@onDismiss').should('have.been.calledOnce') cy.get('[data-cy=toast]').should('not.exist') ``` Reverse those two lines and the toast schedules its dismissal in its first render, against the *real* `setTimeout`. `cy.tick(5000)` then advances a clock that owns no timers, the assertion fails, and the failure looks like a broken component rather than a mis-ordered test. `cy.tick()` also requires that `cy.clock()` has already run — calling it alone is an error, not a no-op. ## The tick-and-assert loop 1. `cy.clock()` — install the fakes, optionally seeded with a timestamp. 2. `cy.mount(...)` — render, with a spy on whatever callback the timer will fire. 3. `cy.tick(ms)` — advance. Every timer whose deadline falls inside that window fires synchronously. 4. Assert — on the spy alias, on the DOM, or on both. Ticking is cumulative, so a polling data grid on a 30-second refresh can be walked forward three intervals with three `cy.tick(30000)` calls, asserting between each. Advancing in one large jump fires the same timers, but you lose the ability to check the state in between. ## The epoch trap `cy.clock()` with no argument starts the clock at Unix time zero. Every `new Date()` inside the component then reads **1 January 1970**, which is invisible until a component renders a relative timestamp — a data grid's "edited 2 minutes ago" column suddenly reports half a century. Three ways out, in order of preference: - **Seed the clock** with a real timestamp: `cy.clock(Date.UTC(2026, 8, 1))`, and let fixtures use dates near it. - **Fake only the timers**, leaving the calendar alone: `cy.clock(null, ['setTimeout', 'clearTimeout'])`. Note that `Date` must be listed explicitly for the current date-time to be overridden at all. - **Move the system time later** without firing anything: `cy.clock().invoke('setSystemTime', someTimestamp)`, which changes the calendar but leaves pending timers where they are. ## Narrowing and restoring `cy.clock()` yields a clock object with `tick(ms)`, `setSystemTime(now)` and `restore()`, reachable through `.then()` or `.invoke()`: | Goal | Write | | --- | --- | | advance time and fire timers | `cy.tick(5000)` | | jump the calendar, fire nothing | `cy.clock().invoke('setSystemTime', ts)` | | hand control back to real timers | `cy.clock().invoke('restore')` | | fake a subset of the globals | `cy.clock(null, ['setTimeout', 'clearTimeout'])` | Restoring mid-test has a sharp edge: timers registered while the fake clock was installed are **discarded**, not resumed. A component that started polling under the fake clock will not poll again unless it re-registers. In practice you rarely need to restore at all, because Cypress does it between tests. ## What changed in Cypress 16 Cypress 16 upgraded its bundled fake-timers library, and the faked `performance` object is now less of a stub: `performance.mark()` and `performance.measure()` actually work while the clock is installed, where previously they were no-ops returning `undefined`, and `performance.timeOrigin` reports a faked value. A component that instruments itself with the User Timing API — an animation-heavy toast or a virtualised grid, for instance — no longer breaks merely because a test faked time.