Cypress E2E Testing | Selectors, cy.intercept, Auth & CI Best Practices

· 18분 읽기 · 수정 intermediate tutorial
Cypress E2E Testing | Selectors, cy.intercept, Auth & CI Best Practices

이 글의 핵심

This English guide follows the Korean Cypress E2E article—first tests, data-testid discipline, cy.intercept fixtures, API login helpers, GitHub Actions—and adds internals on Cypress’s event-driven architecture, network stubbing model, and how teams pair Cypress with unit tests and staging checks before production.

Introduction

Cypress runs end-to-end tests in a browser with a focus on fast feedback and rich debugging. The Korean cypress-e2e-testing-guide covers installation, selectors, cy.intercept, authentication helpers, and CI. This post translates those practices and explains what happens under the hood.

See also Cypress Complete Guide for a broader feature overview.

Architecture: in-browser test driver

Unlike classic WebDriver (remote driver sending commands to a detached browser), Cypress historically optimized around running inside the browser context alongside your app (with architectural nuances evolving across versions). Practically:

  • Commands enqueue on a single event loop—Cypress retries assertions until timeouts, similar in spirit to Playwright’s auto-waiting.
  • The app under test loads in a controlled window, enabling time-travel debugging and consistent screenshots/videos.

Understanding the queue model explains why async mistakes (forgetting to return chainable commands, mixing bare promises incorrectly) surface as flaky tests—stick to Cypress commands and aliases.

Mocking mechanisms: cy.intercept

cy.intercept patches the network layer the browser uses:

  • Stub responses with static JSON or fixtures for deterministic lists and error paths.
  • Alias routes (as('getPosts')) and cy.wait('@getPosts') to synchronize assertions with network completion—prefer this over arbitrary waits.

For GraphQL, intercept the HTTP POST and vary bodies per test. Keep handlers DRY in support files when scenarios repeat.

Coverage instrumentation

Cypress can collect frontend coverage when instrumented builds (Istanbul) are served to the browser—useful for E2E-adjacent metrics but slow and noisy compared to unit coverage. Typical split:

  • Vitest/Jest for line/branch thresholds on modules.
  • Cypress for critical path journeys without chasing coverage parity.

E2E browser automation specifics

  • Cross-browser: Cypress Cloud and product evolution expanded browser support—verify current docs for your target matrix.
  • Parallelization: Cypress Cloud parallelizes across machines; self-hosted CI may run spec files in parallel jobs with split strategies.

Production testing patterns

Cypress targets pre-release automation:

  • Run on every PR against a preview URL or dockerized stack.
  • Staging smoke after deploy—subset of @smoke tagged tests.
  • Production: do not load-test via Cypress; use dedicated tools. Optional read-only synthetic checks may hit health endpoints—separate from developer E2E suites.

Pair E2E with monitoring (APM, RUM, error tracking) because tests cannot observe everything users do.

Selectors and custom commands

Prefer data-testid / data-cy agreed with engineering and QA—stable against CSS refactors. Wrap login flows in custom commands to keep specs short and auth consistent.

CI example (conceptual)

The Korean article shows cypress-io/github-action with Chrome, optional recording, and screenshot artifacts on failure. Ensure the app server is reachable (wait-on, start-server-and-test, or service containers).

Best practices recap

  • Independent tests: seed data per spec; never rely on execution order.
  • No magic sleeps: wait on UI state or intercept aliases.
  • Isolate state: clear storage between tests when the app caches aggressively.