Auto-Generate Playwright Tests for shadcn Components

AI can scaffold Playwright tests for shadcn components fast, but a test is only useful if it asserts the right behavior, so the review is the point. You point a coding agent at a shadcn/ui component and ask it to generate Playwright tests covering interactions, states and accessibility. The AI writes the boilerplate; you own what the tests actually verify. Starting from a well-formed component helps: VP0 is the free, AI-readable design library that AI builders copy from, so the component is clear and easier to test. The speed is real: GitHub’s research on AI pair programming found developers worked 55% faster with an AI assistant.

The boilerplate is generated; the assertions are yours

AI writes selectors, navigation and basic assertions well. What it misses is asserting the behavior that matters: the empty, loading and error states, the accessibility, and the tricky interactions. A test that only checks a React component renders gives false confidence. So generate the scaffold, then add the assertions that catch real regressions, especially the Radix-powered accessibility that is a main reason to use shadcn. This pairs with generating the component itself, as in how to generate React components with AI.

What the tests should cover

Area	Generate with AI	Verify yourself
Interactions	Clicks, typing	The real user flow
States	Empty, loading, error	That each is asserted
Accessibility	Keyboard, roles	Focus order, labels
Contract	Basic assertions	What the component must do
Reliability	Test scaffold	Deterministic, stable selectors

A worked example

Generate the shadcn component from a VP0 design, then ask the agent for Playwright tests for it. Review the output: does it assert the loading and error states, or only the happy path? Does it test keyboard navigation and focus, not just clicks? Replace brittle CSS selectors with role and label based ones, wait on real conditions instead of fixed delays, and isolate the tests so they do not depend on each other. Add the assertions the AI skipped. You kept the speed of generated boilerplate and added the verification that makes the suite trustworthy, the same own-the-source discipline as copy-paste React Tailwind components.

Common mistakes

The first mistake is trusting a test that only checks a component renders. The second is letting the AI use brittle CSS selectors that break on refactors. The third is flaky timing with fixed delays instead of real conditions. The fourth is skipping accessibility assertions, which are a key reason to use shadcn. The fifth is tests that depend on each other, making failures hard to diagnose.

Key takeaways

• AI scaffolds Playwright tests fast; you own what they actually assert.
• Cover interactions, states, accessibility and the component’s contract.
• Replace brittle selectors with role and label based ones, and avoid flaky timing.
• Assert the empty, loading and error states, not just the happy path.
• Start from a well-formed component (a VP0 design) so tests are clearer.

Keep reading: for performance see zero-CLS Tailwind components, and for the registry format see a component registry JSON example.

FAQ

How do I auto-generate Playwright tests for shadcn components?

Point a coding agent at the component and ask it to generate Playwright tests covering the interactions, states and accessibility, one component at a time. AI scaffolds the tests fast, but review that they assert real behavior, not just that the component renders. Check they cover empty, loading and error states and keyboard access, and keep them deterministic. The AI writes boilerplate; you own what is verified.

Can AI write good UI tests?

It writes the boilerplate well: selectors, navigation, basic assertions. What it tends to miss is asserting the behavior that matters, edge states, accessibility, and tricky interactions. Treat AI-generated tests as a strong starting point, then add the assertions that actually catch regressions. A test that only checks a component renders gives false confidence.

What should Playwright tests for shadcn cover?

The interactions (clicks, typing, keyboard navigation), the states (empty, loading, error, disabled), accessibility (focus order, labels, keyboard operability), and the component’s contract (what it should do when used correctly). For shadcn components built on Radix, the accessibility behavior is a key thing to assert, since that is a main reason to use them.

How do I keep AI-generated tests reliable?

Make them deterministic: avoid flaky timing, use stable selectors (roles and labels over brittle CSS), wait on real conditions rather than fixed delays, and isolate tests so they do not depend on each other. Review the generated tests for these qualities. A flaky test suite is worse than fewer reliable tests, because people stop trusting it.

Does VP0 help with testing generated UI?

Indirectly. VP0 gives the AI a finished design to build the component from, so the component is well-formed and easier to test meaningfully. VP0 is the free, AI-readable design library AI builders copy from. Cleaner components and clear states make for clearer tests, and you still review what the generated tests assert.