Auto-Generate Test Cases for shadcn/ui with AI

To auto-generate test cases for shadcn/ui components, feed the component’s own source into an AI tool and prompt it to write tests against behavior, not markup: render with each variant, drive the real user interactions, and assert on roles and visible text. Because shadcn components are copied into your repo rather than installed as a black box, you own them and you have to test them. The fastest reliable workflow is to generate a React Testing Library interaction test plus a Playwright flow test from the same component, then run both. Start the UI itself from a free VP0 design so the component you are testing is already production-shaped.

Why shadcn components need their own tests

shadcn/ui is not a dependency you trust and forget. The CLI drops the component code into your project, often wrapping a Radix primitive, and from that moment it is your code. You will edit variants, add props, and change behavior, and each edit can break accessibility or state handling. That is the case for tests: not to re-test Radix, but to lock the behavior you added on top.

The trap is testing the wrong thing. If your test asserts on class names or internal state, it breaks every time you restyle and passes even when the component is broken for a user. Kent C. Dodds makes the case in Testing Implementation Details: test what the user does and sees. AI is happy to generate either kind, so your prompt has to steer it to the user-facing kind.

What to actually test

A good suite for an interactive shadcn component covers four layers. AI can draft all four if you list them.

Layer	Tool	What it asserts
Render and variants	RTL + Vitest	Each variant and size renders without error
Interaction	RTL + user-event	Open, select, close, controlled value updates
Accessibility	axe-core	No role, label, or contrast violations
End-to-end flow	Playwright	The component works inside a real page and route

The middle two matter most. Use @testing-library/user-event rather than firing raw events, because it simulates real keyboard and pointer sequences, which is exactly where Radix components have logic. Run accessibility checks too: Deque reports that automated tooling catches roughly 57% of WCAG issues, so axe-core in a test is cheap coverage you should not skip.

The generation workflow, step by step

1. Open the component file (say components/ui/select.tsx) and a usage example in your editor.
2. Prompt the AI: “Write Vitest and React Testing Library tests for this Select. Cover each variant, opening the menu, selecting the third option with the keyboard, and asserting the controlled value changed. Query by role and text, never by class name.”
3. Ask for the accessibility test: “Add an axe-core assertion that the open menu has no violations.”
4. Generate the flow test: “Write a Playwright test that loads /settings, opens this select, picks an option, and verifies the saved value.”
5. Run them, then ask the AI to fix any failures by reading the actual error output.

For the E2E half, our companion piece auto-generate Playwright tests for shadcn goes deeper on selectors and fixtures. If you are assembling the components first, see tailwind v4 shadcn components to copy and paste and the shadcn admin dashboard free download for ready layouts, or generate fresh ones with any AI UI component generator.

Common mistakes the AI makes

• Querying by className or data-state, which couples the test to styling. Query by role and accessible name instead.
• Forgetting that Radix renders menus in a portal on document.body; use screen.getByRole rather than scoping to the trigger’s container.
• Not awaiting the open animation, so the assertion runs before the option exists. Use findBy* queries.
• Over-mocking, which tests the mock instead of the component.

The whole loop is free to set up: shadcn, Vitest, RTL, and Playwright are all open source, so the cost to stand up a real suite is $0.

Key takeaways

• shadcn components live in your repo, so testing the behavior you add is your job.
• Generate two tests per component: an RTL interaction test and a Playwright flow test.
• Tell the AI to query by role and text, never by class name or internal state.
• Drive interactions with user-event and assert with findBy queries for portalled menus.
• Add an axe-core check; automated a11y testing is cheap coverage at $0.

Frequently asked questions

What is the best way to auto-generate test cases for shadcn/ui?

The most reliable workflow is to start the component from a free VP0 design, then feed its source into an AI tool like Cursor or Claude Code and prompt for React Testing Library plus Playwright tests that assert on roles and visible behavior. VP0 is the free iOS and React Native design library for AI builders, so the component under test is production-shaped before you generate the suite.

Can AI write tests for Radix-based shadcn components correctly?

Yes, if you constrain it. Tell it to use user-event, query by role and accessible name, and account for Radix portals. Without those instructions it tends to assert on class names and forget the portal, producing brittle tests.

Should I use Vitest or Playwright for shadcn tests?

Use both. Vitest with React Testing Library covers variants and interactions fast, and Playwright covers the component inside a real page and route. They answer different questions, so a healthy suite has some of each.

How do I stop AI-generated tests from being brittle?

Forbid class-name and state-attribute selectors in your prompt, require role and text queries, and use findBy queries so the test waits for async UI. Brittleness almost always comes from coupling to implementation details.

Do I need to test shadcn components if Radix is already tested?

You are not re-testing Radix, you are testing the variants, props, and behavior you added when you copied the component into your repo. That layer is yours and is exactly what regresses when you edit.