Testing Next.js — Vitest and Playwright

Testing is how you gain confidence that your application works and keeps working as you change it, and a Next.js application has distinct layers that call for distinct kinds of tests. There are two broad categories worth understanding: unit and component tests, which verify individual pieces — a utility function, a component's rendering, a validation rule — in isolation and run fast, typically with a tool like Vitest; and end-to-end tests, which drive a real browser through complete user flows — logging in, creating a record, navigating between pages — verifying the whole system works together, typically with a tool like Playwright. The App Router's server-first model adds nuance, because Server Components, Server Actions, and the server-client boundary mean some things are best verified by running the real application in a browser rather than in an isolated unit-test environment.

This topic matters because tests are what let you change a working application without fear of silently breaking it, and the right testing strategy for the App Router is shaped by its architecture in ways that are worth being deliberate about. Without tests, every change risks regressing something you cannot easily check, so you either change cautiously and slowly or boldly and dangerously; with a good test suite, you change freely and let the tests catch what you broke. But testing the App Router naively — trying to unit-test a Server Component that fetches from a database as if it were a pure client component — leads to frustration, because the server-first pieces are entangled with the runtime in ways that resist isolation. The productive approach matches the test type to what is being verified: fast unit tests for the pure logic and presentational components that isolate cleanly, and end-to-end tests in a real browser for the server-rendered flows, data fetching, and full user journeys that are most faithfully verified by running the actual application. Understanding the two test categories, what each is good for, and how the App Router's architecture guides the split between them is what lets you build a test suite that gives real confidence without fighting the framework.

Analogy🏏Cricket

🏏 Think of it like cricket: Picture a Test match where, before the openers walk out, the curator has already prepared the pitch, the umpires are positioned, and the scoreboard is live — the players just play. Plain React is like arriving at an empty ground and being told to roll the pitch, set the field, and wire up the scoreboard yourself before a single ball is bowled. Just as the prepared ground lets the batsmen focus on batting rather than groundskeeping, Next.js prepares routing, rendering, and bundling so you focus on features rather than plumbing. Just as the live scoreboard shows runs the instant a shot is played, server rendering hands the browser finished HTML the instant the page loads. And just as every Test follows the same agreed laws so any team can play anywhere, the App Router's file conventions mean any developer can read the folder structure and instantly know the routes. This reveals why Next.js wins on large teams: shared conventions remove the guesswork that custom setups create.