Cypress Automation

<objective> Production-grade Cypress test suites in TypeScript. The failure this prevents: tests written as if Cypress commands ran synchronously (storing cy.get() in a variable, await cy.click()), and tests that flake because they wait on cy.wait(3000) instead of a network alias. This skill covers the mental model (command queue, retry-ability), project structure, custom commands, network control with cy.intercept, component testing, cross-origin auth with cy.origin, and Cypress Cloud / CI integration. </objective>

Quick Route

Discovery Questions

Check .agents/qa-project-context.md first -- if it exists, use it and skip questions already answered there.

1. Component testing, E2E, or both? Component testing mounts individual components in isolation; E2E tests the full app through the browser. Most projects need both. Component testing requires a framework-specific mount (React, Vue, Angular, Svelte).
2. Cypress Cloud? Cloud provides parallelization, flake detection, analytics, Test Replay, and the AI add-on. If the team uses it, configure projectId and the record key. If not, everything runs locally or in CI without Cloud.
3. TypeScript? Strongly recommended and the default here -- Cypress supports it natively. All examples use TypeScript.
4. Framework and bundler? React + Vite, Next.js + Webpack, Vue + Vite, Angular -- component-testing config depends on this.
5. Cross-origin auth? If login redirects to a separate domain (SSO, OAuth provider), you need cy.origin. Note it now so the login command is built for it.
6. Existing suite or fresh start? If migrating, start with the flakiest or most critical tests, not a big-bang rewrite (see test-migration).

Core Principles

1. Commands Are Enqueued, Not Executed Immediately

The single most important concept. Cypress commands (cy.get, cy.click, cy.type) do not execute when called -- they are added to a queue and run serially, asynchronously. You cannot use async/await with Cypress commands, and you cannot store the return value in a variable.

// WRONG -- this looks synchronous but is not
const button = cy.get('[data-testid="submit"]'); // button is a Chainable, not an element
button.click(); // works only by accident, via chaining

// CORRECT -- chain commands; use .then() when you need a value
cy.get('[data-testid="submit"]').click();

cy.get('[data-testid="price"]').invoke('text').then((text) => {
  const price = parseFloat(text.replace('$', ''));
  expect(price).to.be.greaterThan(0);
});

2. Retry-ability Is Built-In (For Queries, Not Actions)

Cypress automatically retries queries (cy.get, cy.find, cy.contains) and assertions until they pass or time out. It does not retry actions (cy.click, cy.type, cy.select):

• cy.get('.loading').should('not.exist') waits for the indicator to disappear
• cy.get('.item').should('have.length', 5) waits for 5 items
• cy.click() executes once -- if the element is not actionable, it fails

3. Network Control with cy.intercept

cy.intercept intercepts HTTP requests at the network layer -- stub responses, wait for requests to complete, assert on request bodies. Mastering it is the difference between flaky and stable tests. Always wait on a network alias or a DOM assertion, never a fixed cy.wait(ms).

4. Isolation: Each Test Starts Clean

Every it() runs in fresh browser state -- Cypress clears cookies, localStorage, and sessionStorage between tests by default. Tests must not depend on other tests' state or order. Use beforeEach for shared setup, not inter-test dependencies.

5. Data Attributes for Test Selectors

Use data-testid, data-cy, or data-test. They survive CSS refactors, class renames, and localization. Configure the preferred attribute in cypress.config.ts.

Project Structure & Configuration

Standard layout splits e2e/, component/, fixtures/, and support/, with cypress.config.ts at the root configuring both runners. Key config choices: baseUrl from env (never hardcode for CI), explicit viewport, retries.runMode: 2 for CI, and the framework/bundler pair under component.devServer. Component specs live under cypress/component/**/*.cy.tsx.

See references/config-and-commands.md for the directory tree, the complete cypress.config.ts, and the tsconfig.json additions.

Custom Commands

Custom commands encapsulate repeated actions behind a clean, typed API. Common commands: login (via cy.session + API, not UI), a getByTestId selector shorthand, and assertion helpers like shouldShowToast. Declare them in cypress/support/index.d.ts (declare namespace Cypress { interface Chainable { ... } } with JSDoc @example) so they get autocomplete and compile-time checking.

`cy.session` needs a `validate()` callback. cy.session caches cookies/localStorage/sessionStorage automatically, but without validate() the cached session is never re-verified -- a stale or expired token silently reuses a dead session. Always pass a validate() that hits an authenticated endpoint (e.g. cy.request('/api/me').its('status').should('eq', 200)).

Retryable lookups use `Cypress.Commands.addQuery()`, and the callback must be a non-arrow `function () {}` -- Cypress binds this to apply the command timeout, so an arrow function silently breaks retry-ability. (Intercept handlers are the opposite: (req) => {} is fine there because they do not use this.)

See references/config-and-commands.md for the full command definitions, the validate() callback, the addQuery example, and the TypeScript declarations.

cy.intercept Patterns

cy.intercept covers the full network-control surface:

• Stub a response — return canned data with { statusCode, body }, then cy.wait('@alias').
• Spy without stubbing — cy.intercept('POST', '/api/orders').as('createOrder'), then assert on interception.request.body and interception.response?.statusCode.
• Conditional responses — drive a closure with callCount to simulate polling (202 → 200). The handler arrow function (req) => { ... } is correct here.
• Network errors — { statusCode: 500 }, { forceNetworkError: true }, or req.reply({ delay }) for slow responses.
• Modify real responses — req.continue((res) => { ...; res.send(); }).
• Fixture-backed — { fixture: 'api-responses/checkout-success.json' }.

Register the intercept before the action that triggers the request, or the alias never matches.

See references/intercept-patterns.md for runnable code for each, plus cross-origin flows.

Component Testing

Component testing mounts a single component in a real browser without running the full app -- faster than E2E, more visual feedback than unit tests. Use cy.mount(<Component .../>), pass cy.stub()/cy.spy() for callbacks, and assert with the same cy.contains/cy.get chain you use in E2E. Never use cy.visit in a component test. For Vue, use cy.mount(Component, { props: { ... } }).

See references/component-and-fixtures.md for a full React ProductCard component-test suite.