Playwright E2E Testing | Automation· Locators

Playwright E2E Testing | Automation· Locators

· 22분 읽기 · 수정 중급 tutorial
Playwright E2E Testing | Automation· Locators

이 글의 핵심

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.

자주 묻는 질문 (FAQ)

Q. 이 내용을 실무에서 언제 쓰나요?

A. End-to-end testing with Playwright: projects, auto-waiting locators, route mocking, auth storage state, sharded CI, trac… 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.

Q. 선행으로 읽으면 좋은 글은?

A. 각 글 하단의 이전 글 또는 관련 글 링크를 따라가면 순서대로 배울 수 있습니다. C++ 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.

Q. 더 깊이 공부하려면?

A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다.

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

이 글에서 다루는 키워드 (관련 검색어)

Playwright, E2E Testing, Testing, Automation, CI/CD, QA, Frontend 등으로 검색하시면 이 글이 도움이 됩니다.