nextjs-testing

Next.js Testing

Writes tests for Next.js projects, splitting work across a hard boundary: Vitest for anything that doesn't require rendering an async Server Component, Playwright for everything that does. Getting this boundary wrong is the single most common Next.js testing mistake — see reference/async-server-components.md before writing anything. Writing the test files is the deliverable. Running the suite and verifying it — including the fault-injection self-check — is a separate, optional step this skill offers but never runs without being asked. See Step 6.

Progress checklist

Copy this into your response and check items off as you go:

- [ ] 1. Detect stack + router (scripts/detect_stack.sh)
- [ ] 2. Audit project structure; identify Vitest vs Playwright boundary
- [ ] 3. Ask the user what to test (layer + scope) — do not assume
- [ ] 4. State the test plan explicitly
- [ ] 5. Generate tests following AAA, boundary-only mocking
- [ ] 6. Report what was written; offer to run + verify — do not run yet
- [ ] 7. Only if asked: run tests, fault-injection self-check, report results

Step 1 — Detect stack and router

Run scripts/detect_stack.sh from the project root. It confirms this is a Next.js project and reports App Router vs Pages Router — this determines the entire strategy and must be resolved before generating any component test — plus the existing Vitest/Jest, Playwright/Cypress, RTL, MSW, and Zod presence.

If a test runner is already in use, follow it even if a different tool is this skill's default. Never introduce a second, competing test runner.

Step 2 — Audit project structure

Before writing anything, classify the target and route it correctly:

• Async Server Component (contains an await in the component body) → Vitest cannot render this. Either propose extracting the async data call into a plain function (the recommended default — see reference/async-server-components.md) or route the test to Playwright. Never attempt to render it under Vitest.
• Synchronous Server Component or Client Component → Vitest + RTL, same as react-testing.
• Server Action → test as a plain async function with Vitest, not through a rendered tree.
• API route handler (route.ts) or middleware → import the exported function directly and invoke with a constructed Request; see reference/api-and-middleware.md.
• Flag critical paths — authentication, payment/billing, any data-write — for elevated rigor even if the user's request was narrower. State this flag out loud; do not silently expand scope.