playwright-component-testing

Sets up component tests for React or Vue with plain Playwright: small story files show a component in one state, and a gallery page served by your app's dev server displays them for the tests. It needs no separate component-testing runtime, and it covers moving off Playwright's experimental component-testing packages. Your assistant builds the gallery page for your project, since there is no template to copy.

WHEN TO USE

SCOPE

USE FOR

Test a component on its own, with mock data and recorded callbacks.
Compare screenshots of each component state.
Move a test suite off @playwright/experimental-ct-react or -vue.

NOT FOR

Components outside React and Vue: its setup notes cover those two.

This is a saved copy of the skill's SKILL.md instructions. It may differ from the upstream file or the version you install.

In this document (7)

Component Testing with Playwright

Test components with regular Playwright e2e tests against a small story gallery page hosted by the app's own dev server. No extra test runner, bundler integration or npm packages are required.

Concept

A story is a tiny wrapper component that embeds the component under test in one specific scenario: hard-coded props, mock data, providers, recorded callbacks. Stories live next to the component in *.story.tsx (or .ts/.jsx/.js/.vue) files; each named export is one story.
The gallery is a single page you implement to references/gallery-spec.md: it exposes window.mount(params) / window.unmount() that render a story — resolved from your story files (e.g. with import.meta.glob) — into #root. It is framework-specific and yours to own — there is no template to copy for it.
Tests are plain Playwright tests. The built-in mount(storyId, props?) fixture (from @playwright/test) drives the gallery's window.mount and returns a Locator for the gallery root (#root). Scope the queries from there — component.getByRole('button').click(), not component.click(). Nothing to scaffold for it.

Everything the component needs must be set up inside the story (it runs in the browser); everything the test asserts must be observable through the page (DOM, URL, network). Where the component takes callbacks, the story creates the state, provides the callbacks and records the state into a hidden form for the test to assert on. mount(id, props) passes plain serializable props to the story.

Setup workflow

Detect the framework and bundler. React vs Vue decides the framework notes and example story to follow. Then:
- App runs on Vite (has vite.config.*): the gallery is served by the existing dev server at /playwright/gallery/index.html — Vite serves any .html file under the project root, the app's plugins/aliases/CSS apply automatically, and vite build ignores it. No extra server needed.
- Anything else (Next.js, webpack, no dev server): run a small standalone dev server (e.g. Vite) that serves the gallery page, and point baseURL at it. Requires vite and the framework plugin as devDependencies.
Implement the gallery to references/gallery-spec.md: a page at <project>/playwright/gallery/ that renders the requested story into #root. Start from the worked example in the spec and the framework notes in references/react.md / references/vue.md. Keep story discovery (import.meta.glob) and the framework mount here — this is the only framework-specific glue, so keep it small. Import the app's global CSS the same way the app's own entry does.

Configure Playwright — add to playwright.config.ts:

projects: [
  {
    name: 'components',
    testDir: './tests/components',
    use: { ...devices['Desktop Chrome'], baseURL: 'http://localhost:5173/playwright/gallery/index.html', serviceWorkers: 'block', reuseContext: true },
  },
],
webServer: {
  command: 'npm run dev',                                       // or: npx vite --config playwright/vite.config.ts
  url: 'http://localhost:5173/playwright/gallery/index.html',   // standalone server: http://localhost:3100/playwright/gallery/index.html
  reuseExistingServer: !process.env.CI,
},

Match the port to the dev server. mount navigates to baseURL, so set baseURL to the gallery's URL. serviceWorkers: 'block' keeps the app's own service worker from serving cached responses that would shadow your page.route() mocks. reuseContext: true reuses the browser context across tests in a worker (as the old component-testing runtime did) — a large speedup for component suites. If the config already has projects/webServer, merge instead of replacing.

Write a first story next to an existing component, modeled on templates/<react|vue>/Button.story.*.
Write a first spec, modeled on templates/react/button.spec.ts, importing test/expect from @playwright/test.
Run: npx playwright test --project=components. Open http://localhost:5173/playwright/gallery/index.html in a browser to eyeball all stories.

Conventions

Story id: path under src/ without the .story.* extension, plus the export name — src/components/Button.story.tsx export Primary → components/Button/Primary. Any unique suffix works too: mount('Button/Primary'). A .story.vue single-file component is one story, addressable by its path alone (its default export). With gallery types (references/typing.md) ids are prefixed with the package name: acme-ui/components/Button/Primary.
One export per scenario. Prefer a new story export over parameterizing an existing one — stories are greppable, reviewable documentation of component states.

Testing patterns

Examples are React; the Vue equivalents differ only in story syntax.

Callbacks and events

The story owns the state and provides the callbacks. Where the component takes callbacks, create the state inside the story, wire the callbacks to it, and record the state into a hidden form next to the component. Tests perform operations and assert on the recorded values:

export const Stateful = () => {
  const [expanded, setExpanded] = useState(false);
  return <>
    <Expandable expanded={expanded} setExpanded={setExpanded} title="Title">Details</Expandable>
    <form hidden><input data-testid="expanded" readOnly value={String(expanded)} /></form>
  </>;
};

test('click should expand', async ({ mount }) => {
  const component = await mount('components/Expandable/Stateful');
  await component.locator('.codicon-chevron-right').click();
  await expect(component.getByTestId('expanded')).toHaveValue('true');
});

This keeps the whole scenario in the browser: no callback marshalling, the story doubles as documentation, and the recorded state is visible when eyeballing the gallery. Record each observed value in its own data-testid input (String(...) or JSON.stringify(...) for payloads) and assert with toHaveValue() — a web-first assertion that retries until the state lands. The negative direction works the same way: perform the operation, then assert the value did not change.

Per-test props

When a scenario is genuinely parametric (e.g. a boundary-value sweep), pass props as the second argument to mount; the gallery hands them to the story as its props. Keep props to plain serializable data — callbacks belong inside the story.

export const WithTitle = ({ title = 'Default' }: { title?: string }) =>
  <Button title={title} />;

const component = await mount('components/Button/WithTitle', { title: 'Hello' });

Props are type-checked in two optional ways, see references/typing.md: pass the story type as a template argument (mount<typeof WithTitle>('components/Button/WithTitle', { title: 'Hello' }), no setup), or generate gallery types with a small Vite plugin so the id itself is typed (mount('acme-ui/components/Button/WithTitle', { title: 'Hello' }), with autocomplete and rename safety). Vue stories must additionally declare the props at runtime — see the Typed props sections in references/react.md / references/vue.md.

Prop transitions with `update()`

To test how a component reacts to a prop change without remounting (state preserved), call component.update(newProps) — it re-renders the same story with new props on the existing root:

const component = await mount('components/Counter/Default', { value: 1 });
await expect(component.getByTestId('value')).toHaveText('1');
await component.update({ value: 2 });
await expect(component.getByTestId('value')).toHaveText('2');

This requires the gallery to reuse its root/instance (references/gallery-spec.md); state survives as long as the story stays the same.

Multiple states in one test

Each mount() navigates fresh, so tests are fully isolated and mounting several stories in one test is cheap:

await expect(await mount('Button/Primary')).toHaveScreenshot('primary.png');
await expect(await mount('Button/Disabled')).toHaveScreenshot('disabled.png');

For visual comparison, screenshot the returned root locator (as above), not the page, to avoid asserting on browser chrome.

Network mocking

Use page.route() as usual — register routes before mount(), since mounting navigates. serviceWorkers: 'block' (set in the config above) keeps the app's own service worker from serving cached responses that shadow the routes. Teams with MSW handler libraries can start the worker inside a story or decorator instead.

Debugging stories

Open your gallery URL (baseURL) in a browser and call await window.mount({ story: 'components/Button/Primary' }) from the devtools console — that is exactly what the mount fixture does. An unknown story rejects window.mount, which surfaces as the test's mount() throwing with a real stack. To browse without the console, give your gallery an optional index page.

Decision points

Monorepos / non-src layouts: change the glob and the id derivation in your gallery (references/gallery-spec.md) to match, and prefix ids with the package name (references/typing.md).
Global providers (theme, i18n, store, router): create a shared decorator helper next to the gallery and wrap components in stories; see references/react.md / references/vue.md.

References

references/gallery-spec.md — the gallery endpoint contract to implement (start here).
references/typing.md — optional typing for mount: explicit story types vs generated gallery types, with the Vite plugin.
references/react.md — React walkthrough: providers, StrictMode, CSS.
references/vue.md — Vue walkthrough: .story.ts and .story.vue stories, plugins.
references/migration.md — migrating off @playwright/experimental-ct-react / -vue.

One of 3 skills in the microsoft/playwright package — works on its own.

Run this outside your AI tool, using Node.js 22.20.0 or newer. Skills CLI 1.7.2 skips skill selection; prompts cancel installation without an interactive terminal. If choosing Project when asked about installation scope, open your project's folder before running this.

Install checklist

Check selected tools if a picker appears; Claude Code may be unchecked under Additional agents. ↑/↓ moves, Space toggles selections, Enter confirms.
Without a tool picker, check Installing to: for your intended tool. Stop if it names a different tool.
If asked, choose Symlink (Recommended) for shared files or Copy to all agents for separate copies; review the summary before confirming installation.
Install the find-skills skill? defaults to Yes, adding another skill for all projects. Choose No if you don't want that extra installation.

Skills CLI 1.7.2 sends install data to skills.sh by default, including the source, skill names, target tools and file details; GitHub sources are reported only when GitHub confirms the repository is public, while other remote sources can also be reported. Confirmed-public GitHub sources also trigger a security-audit request. Before installing, set the environment variable DO_NOT_TRACK=1 or DISABLE_TELEMETRY=1 to disable both.

npx skills add microsoft/playwright --skill "playwright-component-testing" --full-depth

After installing for Claude Code, open it in the installation project if you chose Project; Global makes the skill available across projects on this computer. Once Claude Code loads the skill, its description helps Claude decide when to use it.

If installation created a top-level skills folder that did not exist when your Claude Code session started, run /reload-skills in that session. Run it again after later changes in that folder.

What's inside

Files included with this skill.

View on GitHub