Cypress Reference

cy.intercept() intercepts network requests made by the application during a test. You can use it to stub responses (return fake data without hitting a real server), mock error conditions (statusCode: 500), simulate slow networks (delay: 2000), or simply observe whether a request was made. It replaces the older cy.route() and is the standard way to control API behavior in Cypress tests. Always alias intercepted requests with .as("name") so you can wait for them with cy.wait("@name").

CSS class names and element structures change frequently during UI development. Using data-testid="submit-btn" attributes creates a stable contract between your application and your tests. They are invisible to users, never affected by styling changes, and make test intentions explicit. This is one of Cypress's official best practices. You can also use aria attributes like aria-label when they convey semantic meaning to users.

The best approach is cy.session(), which caches the session state (cookies, localStorage, sessionStorage) after the first login and restores it for subsequent tests. This avoids repeating the login UI flow on every test run. Alternatively, you can create a custom cy.login() command using Cypress.Commands.add() that performs the login via API (cy.request()) rather than through the UI, which is faster and more reliable.

cy.get() searches the entire document from the root, while cy.find() searches within the previously selected element. For example, cy.get(".parent").find("li") finds all li elements inside .parent, whereas cy.get("li") would find all li elements anywhere on the page. Use cy.find() to scope your queries to a specific container, which makes tests more precise and resilient to changes elsewhere on the page.

Use cy.intercept() with a statusCode of 400, 401, 403, 500, or any error code to simulate error responses. For example: cy.intercept("GET", "/api/data", { statusCode: 500, body: { error: "Server Error" } }) will cause the application to receive a 500 error when it requests /api/data. You can then assert that error messages appear correctly in the UI. This lets you test error handling without needing a real failing server.

Fixtures are static JSON files stored in the cypress/fixtures directory. cy.fixture("users.json") loads the file and returns its parsed contents in a .then() callback. You can use fixtures directly with cy.intercept() by passing { fixture: "users.json" } as the response body, which automatically loads and returns the fixture data. cy.readFile() and cy.writeFile() let you read and write arbitrary files during tests, useful for dynamic data generation.

API seeding means setting up test data and application state through direct API calls (cy.request()) in beforeEach, rather than clicking through the UI. This is faster, more reliable, and isolates the test from UI bugs. For example, instead of navigating to an admin panel to create a user before every test, you call cy.request("POST", "/api/users", { name: "test" }) directly. The Cypress best practices guide recommends API seeding as the primary way to establish test preconditions.

Use cypress.config.js (or cypress.config.ts for TypeScript) to set baseUrl, viewport dimensions, and default timeout values. Environment-specific values (API URLs, credentials) go in the env object within defineConfig(). Access them at runtime with Cypress.env("key"). For CI/CD pipelines, you can override env values by passing --env key=value on the command line. Use the retries configuration (runMode: 2, openMode: 0) to automatically retry flaky tests in CI without impacting local development feedback.