Blog · Testing basics

Next.js testing in layers: unit, end-to-end and the deployed preview

Short answer

Test a Next.js app in layers: unit tests for functions and components, end-to-end tests against a production build, then a check of the deployed preview URL. The preview check catches protection, environment and data differences that a local build cannot.

On this page

Next.js testing is not one tool. Each layer answers a different question, and a green result in one says little about the others. This post sets out the three layers, what each one catches and where a browser check of the deployed URL fits. Facts about Next.js and Vercel come from their documentation, read on November 4, 2026. We make Sybqa, and Sybqa covers only the last layer.

By Sybqa · First published November 4, 2026 · Updated November 4, 2026

The three layers at a glance

Three layers of testing for a Next.js appScroll sideways for more columns.
Layer	Question it answers	Typical tools	Runs against
1. Unit and component	Does this function, hook or component do what I wrote?	Jest or Vitest; Cypress also runs component tests	Your code, in isolation
2. End-to-end	Does a user flow work in a browser on a production build?	Playwright or Cypress	A production build started on your machine or in CI
3. Deployed preview	Does the deployed URL serve the app, with its real settings, at real screen sizes?	Your end-to-end suite pointed at the preview, or a browser QA run	The preview deployment URL

The Next.js testing guide lists five types of test: unit, component, integration, end-to-end and snapshot. It links setup guides for Cypress, Jest, Playwright and Vitest. The three layers here group those types by where they run.

Layer 1: unit and component tests

The Next.js docs describe unit testing as testing individual units of code in isolation, where a unit can be a single function, hook or component. Component testing is the focused version for React components: how they render, how they use props and how they respond to user events. These tests are quick to run, so run them on every change.

The docs also state a limit: because async Server Components are new to the React ecosystem, some tools do not fully support them, and the docs recommend end-to-end testing over unit testing for async components. If a page fetches its data in an async Server Component, cover it in layer 2.

Layer 2: end-to-end tests against a production build

End-to-end tests drive a browser through a user flow, such as signup. The Next.js Playwright guide recommends running tests against your production code to more closely resemble how the application will behave: run npm run build and npm run start, then run npx playwright test in another terminal.

Write end-to-end tests for the few flows that must never break, and end each one with an assertion on the outcome, such as a confirmation heading, not just a page load. The Playwright comparison and the Cypress comparison cover when a scripted suite your team owns is the right choice.

Layer 3: the deployed preview URL

A passing production build on your machine still leaves three questions open. The first two come from Vercel’s documentation; the third follows from the second.

Protection. Vercel’s generated deployment URLs are publicly accessible by default, and Deployment Protection can restrict them. Its Standard Protection scope protects all deployments except production domains and is available on all plans. A test runner without access gets the protection page, not your app.
Environment. Every Vercel environment can define its own environment variables, such as database connection information or API keys. A preview can talk to a different database or service than your local build.
Data. With different settings, the preview can show different content, accounts or feature states from the ones on your machine.

For automated tests, Vercel documents Protection Bypass for Automation, available on all plans: send the project’s secret in an x-vercel-protection-bypass header. Vercel sets one secret as the VERCEL_AUTOMATION_BYPASS_SECRET system environment variable in your deployments. Treat it as a credential and keep it out of screenshots, issue text and shared reports.

Vercel gives each preview two kinds of URL: a branch-specific URL that always points to the latest changes on that branch, and a commit-specific URL that points to the exact deployment of one commit. Test the commit URL when you need a result you can tie to one revision. The Next.js and Vercel preview guide has a full checklist and an evidence card for this layer.

Where Sybqa fits, and where it does not

Sybqa works at layer 3. Paste a preview URL that a browser can reach and describe one journey, review the plan, then start the run. Sybqa opens the URL in a real browser at desktop, phone and narrow widths and reports each check as passed, failed, blocked, not run or needs review, with the evidence.

Sybqa does not replace unit or integration tests. It does not run your test files or look inside Server Components.
It does not send the bypass header. On a protected preview it sees the protection page, not your app. Treat that run as blocked coverage, not a verdict on your app, and either run your own suite with the header or test a URL you have chosen to leave open.
It cannot see your environment variables. It reports what the browser saw. It cannot show that preview settings match production or that a database accepted a write.

A working order for each pull request

Run unit and component tests on every push.
Run end-to-end tests against a production build in CI.
Open the commit-specific preview URL and confirm it serves your app, not a Vercel login or password page.
Run your end-to-end suite against that preview, with the bypass secret held in CI secrets if the preview is protected. A browser QA run such as Sybqa needs a preview it can reach without the header.
After promotion, run a short smoke test on the production domain.

Common questions

Should Next.js end-to-end tests run against the dev server?

The Next.js Playwright guide recommends running them against your production code, with npm run build and npm run start, because that more closely resembles how the application will behave.

Can I unit test async Server Components?

The Next.js testing guide says some tools do not fully support async Server Components yet, and recommends end-to-end testing over unit testing for them.

Does Sybqa replace Jest, Vitest or Playwright?

No. Sybqa checks a deployed URL in a real browser. It does not run your unit, component or integration tests, so keep them.

Sources

Subscribe to new posts (Atom feed)

Try Sybqa on your site

Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.

Add your site link here and it will be waiting in the console after you create an account. Then describe one journey to check and review the test plan before any run starts.