CT vs Vitest + Testing Library?

Vitest with jsdom is faster for logic-heavy components. Playwright CT wins when CSS, layout, or browser APIs dominate—accept slower feedback.

Is Playwright CT stable for enterprise adoption?

It is marked experimental; pin versions and read release notes. Pilot on a design-system package before rolling org-wide.

Where should MSW live?

Prefer a single pattern: either Playwright’s router fixture with shared handlers, or worker startup in playwright/index.tsx—avoid mixing ad hoc page.route calls without conventions.

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

2026년 4월 7일 · 26분 읽기 · 수정 2026년 4월 7일 intermediate tutorial

이 글의 핵심

Playwright Component Testing renders isolated components in a real browser using the same locator and assertion model as E2E. This English guide follows the Korean deep-dive: framework setup, mount vs jsdom, MSW integration, visual regression, CI—and explains the CT bundling pipeline, serialization limits on props, and when to keep Vitest for speed.

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

npm init playwright@latest -- --ct scaffolds playwright/index.html, playwright/index.tsx, and playwright-ct.config.ts.
The CT runner bundles each test plus component entry with Vite (configurable via ctViteConfig).
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