React Testing prompt
Rules that make your coding agent write tests that catch real bugs: Testing Library queries by role, Server Functions tested as functions, MSW for the network and Playwright for the rest.
What it makes your agent good at
Agents write tests that pass and prove nothing: snapshots of whole trees, queries by class name, fetch stubbed by hand, sleeps in end-to-end tests, and attempts to render async Server Components that crash. This prompt gives them a map of what to test where in a React 19 and Next.js 16 app, the current Vitest and Playwright setup, and the checks that make a new test worth keeping.
- Each test at the right levelLogic in node, Client Components in jsdom, layout-heavy widgets in browser mode, async Server Components end to end.
- Vitest 5 as it shipstest.projects that inherit the root config, browser mode through @vitest/browser-playwright, v8 coverage with an explicit include.
- Queries a user would makegetByRole with a name, userEvent.setup() before render, findBy for async content, no test IDs or class selectors by default.
- Server Functions as functionsFormData in, state out, with next/cache, server-only and the session mocked, and redirect asserted by its NEXT_REDIRECT error.
- The network, mocked onceMSW 2 handlers with unhandled requests failing the test, per-test overrides for errors, no hand-written fetch stubs.
- End to end without flakesRole locators, web-first assertions, no fixed waits, storageState sign-in and traces on retry, against a production build.
The React Testing rules
132 lines, current to Vitest 5, React 19.3, Next.js 16.4, Testing Library 16 and Playwright 1.64. Last reviewed October 23, 2026. Plain Markdown, no front matter: each agent's is below.
react-testing.md
# React Testing
You are writing tests for a React 19 app, often on Next.js 16, with Vitest, React Testing Library and Playwright. Write tests for the versions in `package.json`, not the ones in your training data: Vitest moved to `test.projects` and provider packages for browser mode, React 19 removed the old test utilities, and async Server Components cannot be rendered in a unit test.
## Before you write code
Read `package.json` for `vitest` (5.x), `@testing-library/react` (16.x, with `@testing-library/dom` as a peer), `@testing-library/user-event` (14.x), `@playwright/test`, `msw` (2.x), `jsdom` or `happy-dom`, and the test scripts. Use the runner the project has; never add Jest to a Vitest project.
Read `vitest.config.ts`, its setup files and `playwright.config.ts`, and follow the existing layout and names (`*.test.tsx` beside the code, `e2e/*.spec.ts`).
In a Next.js project, read `node_modules/next/dist/docs/01-app/02-guides/testing/` for the installed version.
Run the existing suite once first, so you know which failures were already there.
## What to test where
Pure logic (schemas, formatters, reducers, data access functions): Vitest in the `node` environment. Fast, and most of the suite.
Client Components and hooks: Vitest with React Testing Library in `jsdom` (or `happy-dom`), driven the way a user drives them.
Components that need real layout, focus, pointer events or CSS (positioned popovers, drag, virtualized lists): Vitest browser mode or Playwright, not jsdom with a pile of stubs.
Async Server Components, routing, caching, auth redirects and streaming: Playwright against a production build.
One test per behavior a user or caller can observe. Never test implementation details: internal state, hook call counts, class names, render counts.
## Vitest
// vitest.config.ts
import react from "@vitejs/plugin-react";
import { defineConfig } from "vitest/config";
export default defineConfig({
plugins: [react()],
resolve: { tsconfigPaths: true }, // Vite 8; older Vite needs vite-tsconfig-paths
test: {
coverage: { include: ["app/**", "components/**", "lib/**"], provider: "v8" },
projects: [
{ test: { environment: "node", include: ["**/*.test.ts"], name: "unit" } },
{
test: {
environment: "jsdom",
include: ["**/*.test.tsx"],
name: "dom",
setupFiles: ["./test/setup-dom.ts"],
},
},
],
restoreMocks: true,
},
});
Projects inherit the root config (`extends` defaults to `true` in Vitest 5). The `vitest.workspace` file is gone.
Vitest 5 clears mock calls before each test by default; add `restoreMocks: true`, and `unstubEnvs`/`unstubGlobals` when you stub, so nothing leaks between tests.
Testing Library cleans up after each test only when `globals: true`. Without globals, call `cleanup()` in `afterEach` in the DOM setup file, beside `import "@testing-library/jest-dom/vitest"` for the matchers.
jsdom lacks `ResizeObserver`, `matchMedia`, `scrollIntoView` and pointer capture. Stub one in the setup file when a component needs it; when a test needs many, move it to browser mode.
Browser mode: `browser: { enabled: true, provider: playwright(), instances: [{ browser: "chromium" }] }` with `playwright` from `@vitest/browser-playwright`. Import `page` and `userEvent` from `vitest/browser` and assert with `await expect.element(locator)`, which retries.
Coverage uses `@vitest/coverage-v8`. Set `coverage.include` so untested files count; gate on thresholds the team agreed on, never on 100 percent.
Mock with `vi.mock(path, factory)` (hoisted: share values through `vi.hoisted`), `vi.spyOn`, `vi.stubEnv`, `vi.useFakeTimers()` and `vi.setSystemTime()`. Mock at a boundary you own (the data layer, the session helper), never React or the unit under test.
## React Testing Library
Query like a user: `getByRole` with a `name` first (`getByRole("button", { name: "Save" })`), then `getByLabelText`, then `getByText`. `getByTestId` only when nothing accessible exists, and then fix the markup if you can.
Use `screen`. `findBy*` for anything that appears after an await, `queryBy*` only to assert absence, and `waitFor` with one assertion and no side effects inside.
Create `const user = userEvent.setup()` before `render`, then `await user.click()`, `await user.type()`, `await user.keyboard("{Escape}")`. Use `fireEvent` only for events userEvent cannot produce. With fake timers, `userEvent.setup({ advanceTimers: vi.advanceTimersByTime })`.
Assert what the user perceives: `toBeVisible()`, `toHaveAccessibleName()`, `toBeDisabled()`, `toHaveValue()`, `toHaveAttribute("aria-expanded", "true")`.
Test a hook through a component that uses it, or with `renderHook` from `@testing-library/react`.
Put providers (theme, i18n, a query client created fresh per test) in a `render` helper with a `wrapper` in `test/utils.tsx`.
Snapshot only small, stable values (an inline snapshot of a string or object), never whole component trees.
test("flags an invalid email", async () => {
const user = userEvent.setup();
render(<SignupForm />);
await user.type(screen.getByLabelText("Email"), "nope");
await user.click(screen.getByRole("button", { name: "Sign up" }));
expect(await screen.findByText("Enter a valid email.")).toBeVisible();
expect(screen.getByLabelText("Email")).toHaveAttribute("aria-invalid", "true");
});
## Next.js: Server Components and Server Functions
Testing Library cannot render async Server Components. Do not `render(await Page())`: nested async components, `cookies()` and caching break it. Test the functions the page calls and the synchronous components it renders; cover the page in Playwright.
Test a Server Function as a function: build a `FormData`, call it with a previous state, assert the returned state. Mock the session helper for signed out, wrong user and owner.
Next.js cache and request APIs throw outside a request: mock `next/cache` (`updateTag`, `revalidateTag`, `revalidatePath`, `refresh`) and `next/headers` in these tests. `redirect()` throws an error whose message is `NEXT_REDIRECT`: `await expect(action(state, data)).rejects.toThrow("NEXT_REDIRECT")`.
`import "server-only"` throws under Vitest; mock it once in the setup file: `vi.mock("server-only", () => ({}))`.
Client Components using `useRouter`, `usePathname` or `useSearchParams` need `vi.mock("next/navigation", …)`; Next.js ships no test router.
vi.mock("next/cache", () => ({ revalidateTag: vi.fn(), updateTag: vi.fn() }));
vi.mock("@/lib/session", () => ({ requireUser: vi.fn(async () => ({ id: "u1" })) }));
test("returns a field error for an empty title", async () => {
const data = new FormData();
data.set("title", "");
const state = await createPost({}, data);
expect(state.errors?.title).toBeDefined();
});
## Mocking the network
Mock HTTP with MSW 2, not by stubbing `fetch` or mocking your API client. Keep handlers in `test/handlers.ts`: `http.get(url, () => HttpResponse.json(data))`.
In Vitest: `setupServer(...handlers)` from `msw/node`, `server.listen({ onUnhandledRequest: "error" })` in `beforeAll`, `server.resetHandlers()` in `afterEach`, `server.close()` in `afterAll`. Override per test with `server.use()`, including failures: `HttpResponse.json(body, { status: 500 })` and `HttpResponse.error()`.
In Playwright, `page.route()` sees only the browser's requests. What a Server Component fetches comes from the Next.js server: point it at a test backend or a seeded database through environment variables (Next.js also has an experimental test proxy, `experimental.testProxy`, with an MSW fixture).
## Playwright end to end
Locate with `page.getByRole`, `getByLabel` and `getByText`; narrow with chaining and `filter({ hasText })`, not CSS or XPath.
Use web-first assertions, which retry: `await expect(locator).toBeVisible()`, `toHaveText`, `toHaveURL`, `toHaveCount`. Never `page.waitForTimeout()`, never `expect(await locator.isVisible()).toBe(true)`.
Every test stands alone: its own data, no order dependence. Sign in once in a setup project that saves `storageState`, and reuse it through `dependencies: ["setup"]`.
Config: `webServer: { command: "npm run build && npm run start", url: "http://localhost:3000", reuseExistingServer: !process.env.CI }` and `use: { baseURL: "http://localhost:3000", trace: "on-first-retry" }`. Test the production build: `next dev` compiles on demand and makes tests slow and flaky.
In CI: `forbidOnly: !!process.env.CI`, `retries: 2`, and upload the HTML report and traces when a run fails. Read the trace before changing a test.
`toHaveScreenshot()` for a few layout-critical views only, with dynamic content masked and baselines made on the CI's OS.
With Cache Components, `instant()` from `@next/playwright` asserts what shows before dynamic content streams in.
## Accessibility checks
In Playwright, run `new AxeBuilder({ page }).withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa", "wcag22aa"]).analyze()` from `@axe-core/playwright` on each key page and each open dialog or menu, and expect no violations.
In Vitest, run `axe-core` on the rendered container for component states (errors shown, menu open). jsdom cannot compute color contrast; that check happens in the browser.
Write one keyboard test per interactive flow: Tab to the control, operate it with Enter, Space, arrows and Escape, and check where focus lands.
## Do not
Do not use Enzyme, `react-test-renderer` (deprecated in React 19), `react-dom/test-utils` (only a deprecated `act` is left: import `act` from `react`) or `@testing-library/react-hooks`.
Do not query by class, tag or DOM shape, assert on state or props, or wrap Testing Library calls in extra `act()`.
Do not write `vitest.workspace` files, sleep for fixed times, or let Vitest's include pick up Playwright's `*.spec.ts` files.
Do not mock the unit under test, React itself, or `fetch` globally.
Do not commit `.only`, or a skipped test without a reason in its name.
## Before you finish
Run the type checker, `vitest run` (never watch mode in scripts or CI) and the Playwright tests for the flows you touched.
Make each new test fail once by breaking the code it covers, then restore the code.
Run new end-to-end tests with `--repeat-each=3` to catch flakiness.
Say what unit tests cover, what only end-to-end tests cover, and what is left untested.
10,463 characters, 1,432 words. Under Windsurf's 12,000-character limit for a rule, as every prompt here is.
Use it in your agent
The same rules, where your agent reads them. Each file has the front matter its agent needs, set to load when the task fits.
Claude Code
A rule it loads every session
- Save it as
.claude/rules/react-testing.mdin your project, front matter included, or run the install command. - Its paths front matter loads it when Claude reads or edits a matching file, and keeps it out of other work.
- Prefer one file? Paste it into
CLAUDE.mdunder its own heading instead.
.claude/rules/react-testing.md
---paths: - "**/*.test.ts" - "**/*.test.tsx" - "**/*.spec.ts" - "vitest.config.ts" - "playwright.config.ts"---# React TestingYou are writing tests for a React 19 app, often on Next.js 16, with Vitest, React Testing Library and Playwright. Write tests for the versions in `package.json`, not the ones in your training data: Vitest moved to `test.projects` and provider packages for browser mode, React 19 removed the old test utilities, and async Server Components cannot be rendered in a unit test.## Before you write code- Read `package.json` for `vitest` (5.x), `@testing-library/react` (16.x, with `@testing-library/dom` as a peer), `@testing-library/user-event` (14.x), `@playwright/test`, `msw` (2.x), `jsdom` or `happy-dom`, and the test scripts. Use the runner the project has; never add Jest to a Vitest project.- Read `vitest.config.ts`, its setup files and `playwright.config.ts`, and follow the existing layout and names (`*.test.tsx` beside the code, `e2e/*.spec.ts`).- In a Next.js project, read `node_modules/next/dist/docs/01-app/02-guides/testing/` for the installed version.- Run the existing suite once first, so you know which failures were already there.## What to test where…
Or let the shadcn CLI write this file: sign in (free) for your command.
Cursor
A project rule with front matter
- Save it as
.cursor/rules/react-testing.mdc, front matter included, or run the install command. - Cursor attaches it when you work on matching files, or when the task fits its description.
- Check it under Cursor Settings, Rules, then commit the folder for your team.
.cursor/rules/react-testing.mdc
---description: "Writing or fixing tests in React and Next.js apps: Vitest config, Testing Library queries, Server Function tests, MSW, Playwright and axe."globs: **/*.test.ts,**/*.test.tsx,**/*.spec.ts,vitest.config.ts,playwright.config.tsalwaysApply: false---# React TestingYou are writing tests for a React 19 app, often on Next.js 16, with Vitest, React Testing Library and Playwright. Write tests for the versions in `package.json`, not the ones in your training data: Vitest moved to `test.projects` and provider packages for browser mode, React 19 removed the old test utilities, and async Server Components cannot be rendered in a unit test.## Before you write code- Read `package.json` for `vitest` (5.x), `@testing-library/react` (16.x, with `@testing-library/dom` as a peer), `@testing-library/user-event` (14.x), `@playwright/test`, `msw` (2.x), `jsdom` or `happy-dom`, and the test scripts. Use the runner the project has; never add Jest to a Vitest project.- Read `vitest.config.ts`, its setup files and `playwright.config.ts`, and follow the existing layout and names (`*.test.tsx` beside the code, `e2e/*.spec.ts`).- In a Next.js project, read `node_modules/next/dist/docs/01-app/02-guides/testing/` for the installed version.- Run the existing suite once first, so you know which failures were already there.## What to test where…
Or let the shadcn CLI write this file: sign in (free) for your command.
Windsurf
A workspace rule for Cascade
- Save it as
.windsurf/rules/react-testing.md, or run the install command. trigger: model_decisionlets Cascade pull it in when the task fits its description.- Windsurf reads up to 12,000 characters per rule; this one is 10,463.
.windsurf/rules/react-testing.md
---trigger: model_decisiondescription: "Writing or fixing tests in React and Next.js apps: Vitest config, Testing Library queries, Server Function tests, MSW, Playwright and axe."---# React TestingYou are writing tests for a React 19 app, often on Next.js 16, with Vitest, React Testing Library and Playwright. Write tests for the versions in `package.json`, not the ones in your training data: Vitest moved to `test.projects` and provider packages for browser mode, React 19 removed the old test utilities, and async Server Components cannot be rendered in a unit test.## Before you write code- Read `package.json` for `vitest` (5.x), `@testing-library/react` (16.x, with `@testing-library/dom` as a peer), `@testing-library/user-event` (14.x), `@playwright/test`, `msw` (2.x), `jsdom` or `happy-dom`, and the test scripts. Use the runner the project has; never add Jest to a Vitest project.- Read `vitest.config.ts`, its setup files and `playwright.config.ts`, and follow the existing layout and names (`*.test.tsx` beside the code, `e2e/*.spec.ts`).- In a Next.js project, read `node_modules/next/dist/docs/01-app/02-guides/testing/` for the installed version.- Run the existing suite once first, so you know which failures were already there.## What to test where…
Or let the shadcn CLI write this file: sign in (free) for your command.
GitHub Copilot
Instructions for the repository
- Save it as
.github/instructions/react-testing.instructions.md, or run the install command. - applyTo limits it to the files it's about, in chat, the coding agent and code review.
- Or paste it into
.github/copilot-instructions.md, which Copilot reads for every request.
.github/instructions/react-testing.instructions.md
---description: "Writing or fixing tests in React and Next.js apps: Vitest config, Testing Library queries, Server Function tests, MSW, Playwright and axe."applyTo: "**/*.test.ts,**/*.test.tsx,**/*.spec.ts,vitest.config.ts,playwright.config.ts"---# React TestingYou are writing tests for a React 19 app, often on Next.js 16, with Vitest, React Testing Library and Playwright. Write tests for the versions in `package.json`, not the ones in your training data: Vitest moved to `test.projects` and provider packages for browser mode, React 19 removed the old test utilities, and async Server Components cannot be rendered in a unit test.## Before you write code- Read `package.json` for `vitest` (5.x), `@testing-library/react` (16.x, with `@testing-library/dom` as a peer), `@testing-library/user-event` (14.x), `@playwright/test`, `msw` (2.x), `jsdom` or `happy-dom`, and the test scripts. Use the runner the project has; never add Jest to a Vitest project.- Read `vitest.config.ts`, its setup files and `playwright.config.ts`, and follow the existing layout and names (`*.test.tsx` beside the code, `e2e/*.spec.ts`).- In a Next.js project, read `node_modules/next/dist/docs/01-app/02-guides/testing/` for the installed version.- Run the existing suite once first, so you know which failures were already there.## What to test where…
Or let the shadcn CLI write this file: sign in (free) for your command.
Codex & AGENTS.md
The file most agents read
- Paste it into
AGENTS.mdat your project's root, under its own heading. - Codex reads
AGENTS.mdbefore it starts work, and so do Cursor, Zed, Jules, Amp and Copilot's coding agent. - A folder can have its own
AGENTS.md: the one closest to the file being edited wins.
AGENTS.md
## React TestingYou are writing tests for a React 19 app, often on Next.js 16, with Vitest, React Testing Library and Playwright. Write tests for the versions in `package.json`, not the ones in your training data: Vitest moved to `test.projects` and provider packages for browser mode, React 19 removed the old test utilities, and async Server Components cannot be rendered in a unit test.### Before you write code- Read `package.json` for `vitest` (5.x), `@testing-library/react` (16.x, with `@testing-library/dom` as a peer), `@testing-library/user-event` (14.x), `@playwright/test`, `msw` (2.x), `jsdom` or `happy-dom`, and the test scripts. Use the runner the project has; never add Jest to a Vitest project.- Read `vitest.config.ts`, its setup files and `playwright.config.ts`, and follow the existing layout and names (`*.test.tsx` beside the code, `e2e/*.spec.ts`).- In a Next.js project, read `node_modules/next/dist/docs/01-app/02-guides/testing/` for the installed version.- Run the existing suite once first, so you know which failures were already there.### What to test where…
AGENTS.md is shared with your own instructions, so paste the rules in: the copy sets their headings a level down.
Rules teach it. The MCP equips it. With Pro, your agent installs every component, block and icon it needs, from a prompt.
Get ProMore prompts
Prompts that pair with this one. Each is short enough to sit beside the others.
Pricing
Give your agent the parts, with Pro
The prompts are free. Every Pro plan adds the MCP server, so your agent installs the components, blocks and icons it writes code around.
4.9/5 out of 5 · 150+ reviewsfrom 150+ founders and developers.
Billing
Billed once a year in USD. Cancel anytime.
- How many people can use the license.
- Client work, SaaS products and anything you charge for.
- Page sections in 56 categories, from heroes and pricing tables to dashboards and settings, on every framework and UI library, in your theme.
- Complete Next.js sites for startups, SaaS, agencies and portfolios, every page designed, ready to ship.
- Your AI agent searches, previews and installs any component, block, icon or DESIGN.md from a prompt: 22 tools in Claude Code, Cursor, VS Code and 35 more clients.
- Buttons with motion and states of their own, from an arrow that slides in to a burst of confetti.
- Typewriters, scrambles, counters and more, for headlines, labels and numbers.
- Animated backgrounds for heroes, sections and cards, from a soft aurora to a flock that flees the cursor. Most are pure CSS.
- WebGPU shaders, from a slow aurora to a black hole, each drawing only while it's on screen.
- One design and one theme on all four: the components, blocks and effects are built for each framework.
- React on Base UI, Radix UI, React Aria or Ark UI: install the version for the library your project already uses. Vue, Svelte and Solid run on Ark UI.
- From a button to a date picker, a color picker or a guided tour: accessible, typed in TypeScript, each with live demos.
- Real-world patterns built from the components, in 53 galleries: forms, tables, menus, dialogs and more.
- Area, bar, line, pie, radar and radial charts on TanStack Charts, on every framework. React also gets the Recharts originals.
- Debounce, local storage, media queries and more: each hook is one typed file you own.
- From 222 libraries, Lucide, Heroicons, Tabler and Material Symbols among them, as SVG or a React component in one command.
- Stripe, Linear, Apple and 497 more: a brand's colors, typography and components in one file your AI agent builds from.
- Restyle every component and block at once: 8 styles, 7 grays, 18 colors and 5 radii, shared as a shadcn preset code.
- Priority requests are answered first.
Individual
For personal projects & open source
$32instead of $49/mo
$389 billed yearly
- Seats: 1 seat
- Commercial use: Personal & open source only
- Blocks: All 6,181 blocks
- Templates: All 14 templates
- MCP server: 38 AI clients
- Animated buttons: All 35 buttons
- Text effects: All 97 effects
- Backgrounds: All 100 backgrounds
- Shaders: All 100 shaders
- Frameworks: React, Vue, Svelte, Solid
- UI libraries: Base UI, Radix, Aria, Ark
- Components: All 174 components
- Examples: All 1,103 examples
- Charts: All 70 charts
- React hooks: All 35 hooks
- Icons: 294k+ icons
- DESIGN.md files: All 500 brands
- Theme builder: 8 styles × 18 colors
- Support: Standard
Team
Most popularFor freelancers, agencies & startups
$66instead of $99/mo
$789 billed yearly · ≈ $13/dev/mo
- Seats: Up to 5 seats
- Commercial use: Included
- Blocks: All 6,181 blocks
- Templates: All 14 templates
- MCP server: 38 AI clients
- Animated buttons: All 35 buttons
- Text effects: All 97 effects
- Backgrounds: All 100 backgrounds
- Shaders: All 100 shaders
- Frameworks: React, Vue, Svelte, Solid
- UI libraries: Base UI, Radix, Aria, Ark
- Components: All 174 components
- Examples: All 1,103 examples
- Charts: All 70 charts
- React hooks: All 35 hooks
- Icons: 294k+ icons
- DESIGN.md files: All 500 brands
- Theme builder: 8 styles × 18 colors
- Support: Priority
Organization
For companies with larger teams
$132instead of $199/mo
$1,589 billed yearly
- Seats: Unlimited seats
- Commercial use: Included
- Blocks: All 6,181 blocks
- Templates: All 14 templates
- MCP server: 38 AI clients
- Animated buttons: All 35 buttons
- Text effects: All 97 effects
- Backgrounds: All 100 backgrounds
- Shaders: All 100 shaders
- Frameworks: React, Vue, Svelte, Solid
- UI libraries: Base UI, Radix, Aria, Ark
- Components: All 174 components
- Examples: All 1,103 examples
- Charts: All 70 charts
- React hooks: All 35 hooks
- Icons: 294k+ icons
- DESIGN.md files: All 500 brands
- Theme builder: 8 styles × 18 colors
- Support: Priority
Billed once a year in USD. Cancel anytime.
Individual
For personal projects & open source
$32instead of $49/mo
$389 billed yearly
- How many people can use the license.Seats: 1 seat
- Client work, SaaS products and anything you charge for.Commercial use: Personal & open source only
- Page sections in 56 categories, from heroes and pricing tables to dashboards and settings, on every framework and UI library, in your theme.Blocks: All 6,181 blocks
- Complete Next.js sites for startups, SaaS, agencies and portfolios, every page designed, ready to ship.Templates: All 14 templates
- Your AI agent searches, previews and installs any component, block, icon or DESIGN.md from a prompt: 22 tools in Claude Code, Cursor, VS Code and 35 more clients.MCP server: 38 AI clients
- Buttons with motion and states of their own, from an arrow that slides in to a burst of confetti.Animated buttons: All 35 buttons
- Typewriters, scrambles, counters and more, for headlines, labels and numbers.Text effects: All 97 effects
- Animated backgrounds for heroes, sections and cards, from a soft aurora to a flock that flees the cursor. Most are pure CSS.Backgrounds: All 100 backgrounds
- WebGPU shaders, from a slow aurora to a black hole, each drawing only while it's on screen.Shaders: All 100 shaders
- One design and one theme on all four: the components, blocks and effects are built for each framework.Frameworks: React, Vue, Svelte, Solid
- React on Base UI, Radix UI, React Aria or Ark UI: install the version for the library your project already uses. Vue, Svelte and Solid run on Ark UI.UI libraries: Base UI, Radix, Aria, Ark
- From a button to a date picker, a color picker or a guided tour: accessible, typed in TypeScript, each with live demos.Components: All 174 components
- Real-world patterns built from the components, in 53 galleries: forms, tables, menus, dialogs and more.Examples: All 1,103 examples
- Area, bar, line, pie, radar and radial charts on TanStack Charts, on every framework. React also gets the Recharts originals.Charts: All 70 charts
- Debounce, local storage, media queries and more: each hook is one typed file you own.React hooks: All 35 hooks
- From 222 libraries, Lucide, Heroicons, Tabler and Material Symbols among them, as SVG or a React component in one command.Icons: 294k+ icons
- Stripe, Linear, Apple and 497 more: a brand's colors, typography and components in one file your AI agent builds from.DESIGN.md files: All 500 brands
- Restyle every component and block at once: 8 styles, 7 grays, 18 colors and 5 radii, shared as a shadcn preset code.Theme builder: 8 styles × 18 colors
- Priority requests are answered first.Support: Standard
Team
Most popularFor freelancers, agencies & startups
$66instead of $99/mo
$789 billed yearly · ≈ $13/dev/mo
Everything in Individual, plus
- How many people can use the license.Seats: Up to 5 seats
- Client work, SaaS products and anything you charge for.Commercial use: Included
- Priority requests are answered first.Support: Priority
Organization
For companies with larger teams
$132instead of $199/mo
$1,589 billed yearly
Everything in Team, plus
- How many people can use the license.Seats: Unlimited seats
- Secure checkout via Stripe
- Code lives in your repo
- Keep what you've shipped if you cancel
- License terms
React Testing prompt FAQ
What the React Testing prompt covers and how to use it in your agent.
How do you test async Server Components in Next.js?
How does the React Testing prompt test Server Actions?
Why use MSW instead of mocking fetch in React tests?
How does the React Testing prompt prevent flaky Playwright tests?
Can Playwright mock data fetched by Next.js Server Components?
Does the React Testing prompt include accessibility tests?
Does the React Testing prompt use Vitest or Jest?
Should React component tests run in jsdom, happy-dom or Vitest browser mode?
How does the React Testing prompt keep Testing Library queries accessible?
Does the React Testing prompt allow snapshot tests?
How do I add the React Testing prompt to Claude Code?
How do I use the React Testing prompt as a Cursor rule?
Does the React Testing prompt fit in a Windsurf rule?
Can GitHub Copilot and Codex use the React Testing prompt?
Can I edit the React Testing prompt for my project?
4.9 out of 5 from 150+ developers
Rules teach it. The MCP equips it.
Every component, block and icon, installed by your AI agent on your stack. The prompts stay free.
- Cancel anytime
- Keep what you've shipped