Cypress End-to-End Testing

A selector identifies the DOM elements a test targets, usually passed to cy.get(). You can use CSS selectors, but Cypress recommends dedicated data-cy or data-test attributes so tests do not break when styling or structure changes. Stable selectors decouple tests from incidental markup. Cypress also offers cy.contains() to find elements by text. Choosing resilient selectors is one of the most important practices for keeping end-to-end suites maintainable and resistant to false failures.

A fixture is a file of fixed test data, commonly JSON, stored in the fixtures folder and loaded with cy.fixture(). Fixtures provide consistent, reusable input for tests, such as sample API responses or seed data. They pair well with network stubbing: you can intercept a request and respond with fixture data so tests run deterministically without a live backend. Keeping data in fixtures separates the what of test data from the how of test logic, improving clarity and reuse.

cy.intercept lets you observe and control network traffic. You can spy on requests to assert they happened with certain parameters, or stub them by returning a canned response so the test does not hit a real server. This makes tests faster and deterministic, and lets you simulate edge cases like errors or slow responses. You can also alias an intercept and cy.wait() on it to synchronize the test with asynchronous requests, eliminating arbitrary timeouts.

An assertion verifies that the application is in an expected state, causing the test to fail if the condition is not met. Cypress assertions commonly use .should(), asserting things like an element has certain text, and build on Chai matchers. Cypress automatically retries assertions until they pass or time out, which gracefully handles asynchronous UI updates. Good tests include meaningful assertions about visible behavior rather than implementation details, ensuring the suite confirms the app actually works for users.

A flaky test produces inconsistent results, sometimes passing and sometimes failing even though neither the code nor the test changed. Flakiness commonly stems from timing and race conditions, reliance on arbitrary waits, shared state between tests, or unstable selectors. Flaky tests erode trust in the suite, because developers start ignoring failures. Remedies include waiting on real conditions instead of fixed delays, isolating test data, using stable selectors, and intercepting network calls. Reducing flake is essential for a reliable end-to-end pipeline.