MENU
Testing
Next.js does not ship a bundled test runner, but it is built to work cleanly with the same tools the wider React ecosystem already uses. The framework provides first-class configuration helpers for the most popular ones, so setting up testing in a Next.js project is mostly a matter of picking the right tool for the layer of your app you want to verify.
Tests for a Next.js application generally fall into three categories, and a healthy project usually uses more than one of them together.
Unit and Component Tests
These run in Node.js against a simulated DOM (via jsdom or a similar environment), not a real browser. They are fast and cheap, which makes them ideal for testing pure logic -- utility functions, formatters, reducers, custom hooks -- and for testing individual Client Components in isolation: rendering them, querying the output, and firing simulated events. Jest and Vitest are the two most common runners for this layer in a Next.js project, and React Testing Library is the library almost everyone pairs with either of them to render and query components.
The key limitation of this layer is that async Server Components cannot be rendered directly by these tools -- there is no browser or server runtime backing the simulated DOM, so anything that depends on the actual Next.js server rendering pipeline (data fetching in a Server Component, a Server Action's full request/response cycle, middleware) falls outside what unit and component tests can exercise.
Integration Tests
Integration tests sit between the two extremes: they still run in a simulated environment, but exercise several units together -- a form and the client-side validation logic behind it, or a small tree of components sharing state -- to confirm the pieces cooperate correctly. In practice, most Next.js projects don't maintain a sharply separate "integration" test suite; the same Jest/Vitest plus React Testing Library setup used for component tests naturally scales up to cover multi-component interactions simply by rendering a larger slice of the tree.
End-to-End (E2E) Tests
End-to-end tests run against a real, fully running instance of your application -- built and served (or run in dev mode) exactly as a user would experience it -- driven by an actual browser engine. Because the app is genuinely running, E2E tests are the only layer that can reliably exercise Server Components, Server Actions, route handlers, middleware, redirects, and the full network request/response flow between client and server. Playwright is the tool most commonly used for this in the Next.js ecosystem (Cypress is a popular alternative). E2E tests are slower and more expensive to run than unit or component tests, so most teams write comparatively few of them, reserving them for critical user flows -- checkout, sign-in, the primary navigation path -- rather than every edge case.
Choosing a Combination
| Pure functions, formatters, data transforms | Unit tests with Jest or Vitest -- no rendering involved. |
| Client Components (forms, toggles, interactive widgets) | Component tests with React Testing Library on top of Jest or Vitest. |
| Server Components, Server Actions, route handlers, full pages | End-to-end tests with Playwright against a real running server. |
| Large, slow test suite in CI | Consider migrating the unit/component layer from Jest to Vitest for faster feedback. |
The following pages cover each tool in turn: Jest, React Testing Library, Playwright, and Vitest.