home / skills / bobmatnyc / claude-mpm-skills / cypress

This skill helps you implement robust Cypress E2E and component tests with stable selectors, deterministic waits, network control, and CI-friendly patterns.

npx playbooks add skill bobmatnyc/claude-mpm-skills --skill cypress

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
4.5 KB
---
name: cypress
description: "Cypress end-to-end and component testing patterns for web apps: reliable selectors, stable waits, network stubbing, auth handling, CI parallelization, and flake reduction"
version: 1.0.0
category: toolchain
author: Claude MPM Team
license: MIT
progressive_disclosure:
  entry_point:
    summary: "Write reliable Cypress E2E and component tests with stable selectors, deterministic waits, and network control"
    when_to_use: "When building browser E2E suites, debugging flaky UI tests, validating critical user flows, or adding component tests to a modern frontend"
    quick_start: "1. Install Cypress 2. Add data-testid selectors 3. Use cy.intercept for network control 4. Avoid fixed sleeps 5. Run in CI with artifacts"
  token_estimate:
    entry: 130
    full: 5200
context_limit: 900
tags:
  - javascript
  - testing
  - cypress
  - e2e
  - component-testing
  - ci
  - flake-reduction
requires_tools: []
---

# Cypress (E2E + Component Testing)

## Overview

Cypress runs browser automation with first-class network control, time-travel debugging, and a strong local dev workflow. Use it for critical path E2E tests and for component tests when browser-level rendering matters.

## Quick Start

### Install and open

```bash
npm i -D cypress
npx cypress open
```

### Minimal spec

```ts
// cypress/e2e/health.cy.ts
describe("health", () => {
  it("loads", () => {
    cy.visit("/");
    cy.contains("Hello").should("be.visible");
  });
});
```

## Core Patterns

### 1) Stable selectors

Prefer `data-testid` (or `data-cy`) attributes for selectors. Avoid brittle CSS chains and text-only selectors for critical interactions.

```html
<button data-testid="save-user">Save</button>
```

```ts
cy.get('[data-testid="save-user"]').click();
```

### 2) Deterministic waiting (avoid fixed sleeps)

Wait on app-visible conditions or network aliases rather than `cy.wait(1000)`.

```ts
cy.intercept("GET", "/api/users/*").as("getUser");
cy.visit("/users/1");
cy.wait("@getUser");
cy.get('[data-testid="user-email"]').should("not.be.empty");
```

### 3) Network control with `cy.intercept`

Stub responses for deterministic tests and speed. Keep a small set of “real backend” smoke tests separate.

```ts
cy.intercept("GET", "/api/users/1", {
  statusCode: 200,
  body: { id: "1", email: "[email protected]" },
}).as("getUser");
```

### 4) Authentication strategies

Prefer `cy.session` to cache login for speed and stability.

```ts
// cypress/support/commands.ts
Cypress.Commands.add("login", () => {
  cy.session("user", () => {
    cy.request("POST", "/api/auth/login", {
      email: "[email protected]",
      password: "password",
    });
  });
});
```

```ts
// e2e spec
beforeEach(() => {
  cy.login();
});
```

## Component Testing

Run component tests to validate UI behavior in isolation while keeping browser rendering.

```bash
npx cypress open --component
```

```ts
// cypress/component/Button.cy.tsx
import React from "react";
import Button from "../../src/Button";

describe("<Button />", () => {
  it("clicks", () => {
    cy.mount(<Button onClick={cy.stub().as("onClick")}>Save</Button>);
    cy.contains("Save").click();
    cy.get("@onClick").should("have.been.calledOnce");
  });
});
```

## CI Patterns

### Artifacts (videos/screenshots)

Store artifacts for failed runs and keep videos optional to reduce storage.

```ts
// cypress.config.ts
import { defineConfig } from "cypress";

export default defineConfig({
  video: false,
  screenshotOnRunFailure: true,
  retries: { runMode: 2, openMode: 0 },
});
```

### Parallelization (Cypress Cloud)

Parallelize long E2E suites via Cypress Cloud when runtime dominates feedback loops.

## Anti-Patterns

- Use `cy.wait(1000)` as a synchronization mechanism.
- Select elements via deep CSS paths.
- Mix heavy network stubbing with “real backend” assertions in the same spec.
- Depend on test order; isolate state with `cy.session` and per-test setup.

## Troubleshooting

### Symptom: flaky click or element not found

Actions:
- Add a `data-testid` hook for the element.
- Assert visibility before interaction (`should("be.visible")`).
- Wait on network alias for the data that renders the element.

### Symptom: tests fail only in CI

Actions:
- Increase run-mode retries and record screenshots on failure.
- Verify viewport and baseUrl config match CI environment.
- Eliminate reliance on local-only seed data; create data via API calls.

## Resources

- Cypress docs: https://docs.cypress.io/
- Best practices: https://docs.cypress.io/guides/references/best-practices

Overview

This skill provides practical Cypress end-to-end and component testing patterns that reduce flakiness and speed up feedback loops. It covers reliable selectors, deterministic waits, network stubbing, auth handling, CI artifact strategies, and parallelization guidance. The content is focused on actionable patterns you can apply to web apps to make browser tests more maintainable and reliable.

How this skill works

The skill explains core techniques: use stable data-* selectors, avoid fixed sleeps by waiting on network aliases or UI conditions, and control network responses with cy.intercept for deterministic tests. It also demonstrates component testing with cy.mount, caching logins using cy.session, and CI configuration for retries, artifacts, and parallel runs. Practical code snippets illustrate each pattern so you can apply them directly.

When to use it

  • Writing critical-path end-to-end tests that must be stable across environments
  • Authoring component tests that need real browser rendering without full E2E overhead
  • Reducing flakiness caused by timing or network variability
  • Speeding up test suites by stubbing slow or flaky backend calls
  • Configuring CI pipelines for artifacts, retries, and parallelization

Best practices

  • Prefer data-testid or data-cy attributes for selectors instead of deep CSS or text-only selectors
  • Wait on network aliases (cy.intercept + cy.wait) or app-visible assertions rather than fixed sleeps
  • Use cy.intercept to stub slow or non-deterministic network responses and keep a few real-backend smoke tests separate
  • Cache authentication with cy.session to avoid repeated login flows and isolate state per test
  • Store screenshots for failures, keep videos optional, and configure retries for run mode in CI

Example use cases

  • E2E test that visits a user page, waits for GET /api/users/:id, then asserts UI fields
  • Component test that mounts a Button and verifies click handlers using cy.mount and cy.stub
  • CI configuration that disables video, enables screenshots on failure, and sets retries for flaky runs
  • Stubbing a login API in tests to run deterministic flows while keeping a separate real-login smoke test
  • Parallelizing long E2E suites via Cypress Cloud to reduce total run time

FAQ

Should I stub every network request?

No. Stub nondeterministic or slow endpoints to make tests fast and reliable, but keep a small set of real-backend smoke tests to validate integration.

When is cy.session preferred over UI login?

Use cy.session when you want speed and stability across many tests; keep at least one test that performs a real UI or API login to validate the auth flow.