Testing Strategies for the App Router

The plain-language idea

An App Router app has three genuinely different kinds of code, and they need three different testing approaches — reaching for one tool everywhere is how teams end up either under-tested or fighting their test runner.

Server Component logic — the data-fetching and transformation that happens inside an async Server Component — usually isn't worth rendering in a test at all. It runs on the server, has no client-side behavior, and most of its complexity is really just "take this data, shape it correctly." Pull that shaping logic into a plain, exported function and unit test the function directly; there's nothing React-specific left to test.

Route Handlers (route.ts files) are ordinary request-in, response-out functions — test them as integration tests, calling the exported GET/POST with a real Request and asserting on the real Response, no browser needed.

Client Components with real interactivity — a form, a toggle, anything with useState or an event handler — are what component-testing tools are actually built for. That's where React Testing Library or a browser-based runner earns its keep.

See it in a real thing: testing each layer with the right tool

Pull the shaping logic out of the Server Component so it's a plain function:

// app/dashboard/get-summary.ts
export function summarize(orders: { total: number }[]) {
  return {
    count: orders.length,
    revenue: orders.reduce((sum, o) => sum + o.total, 0),
  };
}

// app/dashboard/get-summary.test.ts
import { describe, it, expect } from "vitest";
import { summarize } from "./get-summary";

describe("summarize", () => {
  it("sums revenue across orders", () => {
    expect(summarize([{ total: 10 }, { total: 25 }])).toEqual({
      count: 2,
      revenue: 35,
    });
  });
});

page.tsx just calls summarize(await getOrders()) and renders the result — there's no separate test for the page, because there's no logic left in it worth testing in isolation.

A Route Handler gets tested by calling it directly, no server or browser required:

// app/api/orders/route.test.ts
import { describe, it, expect } from "vitest";
import { GET } from "./route";

describe("GET /api/orders", () => {
  it("returns 200 with an array", async () => {
    const res = await GET(new Request("http://localhost/api/orders"));
    expect(res.status).toBe(200);
    expect(Array.isArray(await res.json())).toBe(true);
  });
});

What people usually miss

Watch out

• React Testing Library can't render an async Server Component the normal way. RTL's render() expects a synchronous component; an async function Page() isn't one. This is exactly why pulling logic into a plain function is the fix, not a workaround for a missing RTL feature — the component itself often has nothing left worth unit testing.
• A Route Handler test isn't an end-to-end test. Calling GET directly skips real HTTP, middleware, and the actual deployed runtime — it proves the handler's own logic is correct, not that the full request pipeline in front of it is wired up right. Both are worth having.
• Mocking fetch in a Server Component test usually means you're testing the wrong layer. If a test needs to mock the network to check a rendering decision, that decision — not the fetch — is what should have been pulled into a plain, testable function in the first place.

The genealogy: this follows straight from how the App Router splits Server and Client Components

The reason these three testing approaches don't collapse into one is the same server/client split this track's earliest lessons on the file-convention model cover — a Server Component runs only on the server and produces no client-side behavior to test, a Client Component runs in the browser and is exactly what component-testing tools target, and a Route Handler is neither, just a function. Knowing which category a piece of code falls into is what tells you which tool to reach for.