Testing Overview
Next.js doesn't force a single testing tool on you — it's framework-agnostic here, and officially documents integrations with several popular tools. What matters more than the specific library is understanding the different layers of testing you can apply to an App Router project, and what each layer is actually good at catching.
The testing pyramid
A healthy test suite is shaped like a pyramid: lots of small, fast, cheap tests at the bottom, and progressively fewer, slower, more expensive tests as you move up toward full end-to-end coverage. Each layer catches different classes of bugs, and each layer gets more realistic — and more expensive to run — as you go up.
The three layers
Layer | What it tests | Typical tools | Speed |
|---|---|---|---|
Unit tests | A single function or module in isolation — pure logic, utilities, formatters | Jest, Vitest | Very fast (milliseconds) |
Component tests | A single React component's rendered output and behavior, in isolation from the rest of the app | React Testing Library + Jest/Vitest | Fast (tens of milliseconds) |
End-to-end (E2E) tests | A real user flow through the running app in an actual browser — navigation, forms, multiple pages | Playwright, Cypress | Slow (seconds per test) |
Unit tests give you confidence in your business logic — a discount calculation, a date formatter, a validation rule — without needing to render anything.
Component tests give you confidence that a piece of UI renders correctly and responds to user interaction the way a real user would experience it.
E2E tests give you confidence that entire flows work end to end, across pages, real network calls (or realistic mocks), and actual browser behavior.
Where to go next
This overview stays intentionally high level. Two dedicated pages go deeper on the layers you'll write the most of day to day:
Unit Testing (Jest & Vitest) — setting up either runner with Next.js, and writing your first test for a plain utility function.
Component Testing — using React Testing Library to test Client Components the way users actually interact with them, and why Server Components need a different approach.