Write a test strategy for App Router code that doesn't pretend Server Components unit-test like hooks

You are designing a test strategy for a piece of App Router code, and the first job is classifying what kind of test that specific code actually supports, rather than defaulting to the same unit-test pattern used for client-side hooks and components regardless of what's actually being tested.

CODE TO TEST
app/api/orders/route.ts (POST handler that validates and creates an order) and app/orders/[id]/page.tsx (an async Server Component that fetches and renders order details)

CODE TYPE
The route.ts file is a Route Handler; the page.tsx file is a Server Component

EXISTING TEST SETUP
Vitest for unit tests, Playwright already configured for a small number of existing e2e flows

KEY BEHAVIORS TO COVER
POST /api/orders returns 400 on an invalid payload, 201 with the created order on success; the order detail page shows a not-found state for a deleted or inaccessible order id

TESTING RULES
If this is a Route Handler, test it directly and cheaply: import the exported GET, POST, or other method function and call it with a real, constructed Request object, then assert on the returned Response's status and body — this needs no browser, no rendering, and no test server, since a Route Handler is just an async function that takes a Request and returns a Response, and testing it as exactly that is both the simplest and the most accurate representation of what it actually does in production. If this is a Server Action, test it the same way: it's a plain async function once you have a reference to it, so call it directly with constructed FormData or arguments and assert on its returned value, mocking only the actual external dependency named below, such as a database client or an external API call — do not reach for a browser-based test to exercise a Server Action's own logic when a direct function call tests the identical code path with far less setup and far less flakiness. If this is a Server Component, be honest about the real limitation: it's an async function that can't be rendered synchronously the way React Testing Library renders a client component, and there's no first-party, widely adopted pattern for unit-rendering an async Server Component the way there is for a client one — the realistic options are testing the plain data-fetching and transformation logic it calls as ordinary functions, separate from the JSX it returns, or verifying the actual rendered output through an integration or end-to-end tool like Playwright that runs a real browser against a real running instance of the app; recommend whichever fits the specific behavior being verified, and say plainly if the honest answer is that a given behavior is better covered by end-to-end testing than forced into a unit test that would only prove the function didn't throw. Mock only at the actual external boundary — the database client, the third-party API, the mailer — never by reaching into the framework's own internals (a Request/Response implementation, Next.js's own caching layer) to fake behavior that a real Request/Response object already provides correctly and for free. Cover both the success path and every named failure mode explicitly — a Route Handler test suite that only exercises a 200 response has not actually tested the validation-failure or not-found branches that live in the same function, even though those branches are just as reachable as the success path in real traffic.

OUTPUT FORMAT
For each piece of code listed, state which category it falls into (directly testable, or needs integration/e2e) and why, then the actual test code for whatever is directly testable, and a one-line note on what the untestable-at-the-unit-level parts should be verified with instead.