🚨 Common Errors

Common Errors: The selector is wrong, or the element hasn't been rendered into the DOM yet — usually the app is still loading data, the element appears to be "waited for" but the

The selector is wrong, or the element hasn't been rendered into the DOM yet — usually the app is still loading data, the element appears to be "waited for" but the default 4-second timeout expires first.

The app redirects to a different superdomain, such as an OAuth/SSO provider; Cypress controls only one origin at a time by default.

The baseUrl in cypress.config.js is wrong, or the local dev server hadn't started yet when the test began.

The file doesn't exist in cypress/fixtures/, or the extension/path is wrong.

cy.wait('@alias') was called but the matching network request never fired — usually the intercept's URL pattern doesn't match the real request, or the intercept was defined AFTER cy.visit() and missed the request.

An uncaught JavaScript error in the application (or a third-party analytics/widget script) is automatically turned into a test failure by Cypress.

Frameworks like React/Vue remove and re-insert an element during a re-render (the Cypress equivalent of Selenium's StaleElementReferenceException).

Some UI libraries (charts, data grids) use ResizeObserver; this harmless browser warning is sometimes caught by Cypress as an uncaught exception and fails the test.

"Test isolation" is on by default since Cypress v12+: cookies/localStorage/sessionStorage are automatically cleared before every test. If a test relies on login/state left behind by a previous test, it breaks when run together.

An object returned by cy.fixture() is shared by reference in JavaScript; if you mutate it in one test (e.g. data.used = true), the "dirty" data leaks into the next test.

🎬 The Test That "PASSes" But Is Secretly Running on Dirty Data

Test 1: updates profile

Test 2: expects a fresh user

used: true (leaked!)