How do you balance unit, integration, and end-to-end tests in Next.js?

WHAT THIS TESTS: The interviewer wants to know if you can scale quality without bankrupting CI minutes or developer patience. In a Next.js app, the stack spans Node.js server runtimes, React Server Components, client hydration, and edge networks, so a senior engineer must decide where to mock, where to integrate, and where to exercise the real browser. This question reveals whether you think in total cost of ownership or just in code coverage percentages.

A GOOD ANSWER COVERS: First, define the pyramid ratios and justify them with real trade-offs. Unit tests with Jest or Vitest should dominate around 70 percent of the suite because they run in milliseconds and give precise failure signals; use them for utilities, hooks, and isolated React components. Integration tests should occupy roughly 20 percent and target Next.js specific boundaries like data fetching in Server Components, Route Handler logic, and client transitions between pages; these validate that wiring works without spinning up a full browser. End-to-end tests with Playwright or Cypress should cover the remaining 10 percent and focus only on business-critical user flows such as checkout or authentication; they are slow, expensive, and flaky but provide the highest confidence. Second, explain environment differences. Server Components execute in a Node.js sandbox, so unit testing them may require specific configuration, while client components need a browser-like environment or jsdom. Third, discuss cost and speed in concrete terms. A thousand unit tests might finish in under ten seconds, a hundred integration tests in under a minute, but fifty end-to-end tests could take ten minutes and consume significantly more CI compute. Fourth, mention test collateral like fixtures, factories, and mocking strategies for fetch or cookies so the suite stays maintainable as the app grows.

COMMON WRONG ANSWERS: A red flag is proposing majority end-to-end coverage because it sounds safer; in reality this creates a slow, brittle suite that developers ignore. Another red flag is treating all React components the same regardless of whether they are Server or Client Components; this leads to incorrect mocks and tests that pass in CI but fail in production. Saying you test everything with unit tests and skip integration testing is also weak because it misses framework-specific lifecycle bugs like cache invalidation or middleware redirects. Finally, ignoring the distinction between testing logic and testing Next.js framework behavior shows a shallow understanding of the platform.

LIKELY FOLLOW-UPS: The interviewer may ask how you test middleware or edge runtime logic without a browser. They might ask how you handle authentication state in Playwright or Cypress without hitting a real identity provider on every run. Another follow-up is how you parallelize end-to-end tests in CI to keep build times under five minutes, or how you use Next.js experimental test mode or MSW to intercept network requests during integration tests.

ONE CONCRETE EXAMPLE: Imagine a large e-commerce site using the Next.js App Router. You would write unit tests for a price calculation hook and a product card component using Vitest and React Testing Library. You would write integration tests for the server-side product detail page to ensure fetch caching and revalidation tags behave correctly using a test database in Docker. You would reserve end-to-end tests for the complete purchase flow from add-to-cart through Stripe webhook confirmation using Playwright, running only against the staging deployment on pull requests.