Playwright E2E Testing | Automation, Locators, Network Mocking, CI & Visual Tests

· 22분 읽기 · 수정 intermediate tutorial
Playwright E2E Testing | Automation, Locators, Network Mocking, CI & Visual Tests

이 글의 핵심

This guide translates the practical Playwright E2E Korean post—installation, locators, interactions, network interception, auth setup, CI—and adds internals: browser contexts, CDP, parallelism, trace artifacts, and production-adjacent patterns like synthetic checks against staging.

Introduction

Playwright is Microsoft’s cross-browser automation library for E2E tests. The Korean playwright-e2e-testing-guide walks through installation, first specs, locators, interactions, API mocking, auth reuse, a commerce flow, CI, and screenshots. This English version preserves that structure and adds architecture and operations context.

For a broader feature tour, see Playwright Complete Guide.

Test runner and browser architecture

Processes and contexts

  • Playwright Test (the @playwright/test runner) schedules tests across worker processes for isolation.
  • Each worker launches browser instances (Chromium, Firefox, WebKit) as needed.
  • A BrowserContext is a lightweight isolated session—cookies, storage, permissions—ideal for parallel tests without cross-talk.
  • Pages live inside contexts; your test fixture receives a page tied to one context per test by default.

Chrome DevTools Protocol (CDP) and friends

For Chromium, Playwright commands flow through CDP (and similar protocols for other engines). That is why actions like tracing, network interception, and screenshots feel first-class: the runner controls the browser at the same layer as DevTools.

Auto-waiting

Playwright retries actions until timeouts if elements are actionable. This reduces flakiness compared to older drivers that required manual sleep—but you still must choose stable locators (getByRole, getByLabel) and deterministic data.

Mocking mechanisms

page.route and page.waitForResponse let you stub HTTP or assert real calls:

  • Stub with route.fulfill for fast, deterministic UI states.
  • Observe with waitForResponse after a user action to tie assertions to network completion.

For GraphQL or REST, prefer handlers centralized in fixtures so scenarios stay readable.

Coverage instrumentation

E2E tests generally do not drive line coverage the way Istanbul does for unit tests. If you need coverage:

  • Instrument the frontend bundle in CI (e.g., babel-plugin-istanbul) and merge reports—or
  • Treat E2E as journey coverage (critical paths) separate from unit coverage metrics.

Mixing concerns often creates slow pipelines; keep unit coverage on Vitest/Jest and E2E on critical flows.

E2E browser automation at scale

  • Projects in playwright.config.ts map to browser/device matrices—run selectively in PR vs nightly.
  • Sharding: npx playwright test --shard=1/4 splits work across CI jobs.
  • Retries on CI absorb transient failures—pair with trace: ‘on-first-retry’ to debug.

Production testing patterns

  • Preview deployments: run the same suite against every PR’s URL.
  • Staging smoke: shorter subset after deploy.
  • Synthetic monitoring: scheduled Playwright (or lighter HTTP checks) against canary endpoints—never against production write paths without safeguards.
  • Feature flags: assert both flag states in separate projects or tagged tests.

Config and first tests (summary)

The Korean article includes playwright.config.ts with webServer to start npm run dev, multi-browser projects, and sample specs for login and e-commerce flows. Copy those patterns, then tighten timeouts, baseURL, and storageState for your app.

CI snippet

- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test
- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: playwright-report
    path: playwright-report/

Upload traces and HTML reports on failure—they explain flakiness faster than screenshots alone.

Visual testing

expect(page).toHaveScreenshot() compares pixels—stabilize fonts, animations, and viewport. Use maxDiffPixels when anti-aliasing differs slightly between CI and laptops.