Playwright Component Testing | React, Vue, Svelte, MSW & CI

Role in the testing pyramid

Layer	Tooling	Strength
Unit / integration (Node)	Vitest, Jest + RTL	Speed, logic
Component (browser)	Playwright CT, Cypress CT	Layout, real events
E2E	Playwright, Cypress	Full user journeys

Component Testing validates a widget-sized surface—modal, table row, form section—without navigating the whole app.

---

Architecture: mount pipeline

1. npm init playwright@latest -- --ct scaffolds playwright/index.html, playwright/index.tsx, and playwright-ct.config.ts.
2. The CT runner bundles each test plus component entry with Vite (configurable via ctViteConfig).
3. The mount fixture renders your component into the test shell; the return value behaves like a locator to the mounted root—reuse familiar click, screenshot, and getByRole APIs.

Props must stay serializable; complex live objects from Node do not cross cleanly—wrap with test doubles or wrapper components.

---

Mocking mechanisms

• MSW: Share handlers with your app. The Korean guide shows router.use(...) with http handlers—keeps API contracts aligned with Storybook or frontend mocks.
• page.route: Quick one-off stubs; good for spikes, easy to fragment conventions if overused.
• beforeMount hooks: Inject routers, themes, i18n—mirror production providers in playwright/index.tsx to avoid style-less or locale-missing renders.

---

Coverage instrumentation

CT runs a browser bundle; collecting Istanbul/V8 coverage requires enabling coverage in the CT toolchain (version-specific). Many teams skip line coverage for CT and rely on screenshots + behavioral assertions, while keeping Vitest coverage for business logic.

If you must merge coverage, plan report merging in CI and watch for path mapping mismatches between CT and unit runs.

---

Visual regression

toHaveScreenshot() on the mounted root catches unintended style changes. Mitigate OS/font drift with consistent CI images, document.fonts.ready, and tolerance options.

---

E2E vs CT boundaries

• CT: Single component, fast feedback compared to full E2E, slower than jsdom.
• E2E: Validates routing, real backends, auth cookies across pages.

Use both: CT for design system regressions; E2E for checkout and permissions.

---

Cypress CT comparison

Topic	Cypress CT	Playwright CT
API	Cypress chains	Playwright locators/assertions
Browsers	Often Chromium-focused setups	Multi-browser projects
Maturity	More historical examples	Newer, experimental flag
Debugging	Time-travel style	Trace Viewer shared with E2E

Teams already on Playwright E2E usually consolidate tooling; Cypress-heavy teams may stay on Cypress CT.

---

CI

npx playwright install --with-deps chromium
npx playwright test -c playwright-ct.config.ts

Shard large suites; store HTML reports and traces as artifacts.

---

Production testing patterns

CT runs in CI and optional pre-publish jobs—not in production. Combine with:

• Storybook visual tests or Chromatic for design review.
• E2E smoke on staging after deploy.
• Monitoring separate from test suites.

---

References

• Playwright Component Testing docs

---

자주 묻는 질문 (FAQ)

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

A. Mount UI components in real browsers with Playwright CT: experimental CT packages, Vite bundling, mount fixture, MSW rou… 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.

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

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

Q. 더 깊이 공부하려면?

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

---

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

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

• Cypress E2E Testing | Selectors· cy.intercept
• Vitest Browser Mode | Real Browser Tests
• Playwright E2E Testing | Automation· Locators

---

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

Playwright, Component Testing, E2E, Visual Testing, React, Vue, Svelte 등으로 검색하시면 이 글이 도움이 됩니다.