Next.js test HTTP server

[calebmer]

Feature request

I’d like to be able to test servers built with Next.js that have heavy HTTP logic (e.g. cookies, form uploads) in getServerSideProps using standard Node.js HTTP testing frameworks/libraries like Jest/Mocha or supertest.

Ideally I’d like for the server code to run in the same Node.js process as the test so that I can mock functions, mutate internals (e.g. set feature-flags on the fly), or assert on internal process state.

I recognize this feature request is a bit difficult since Next.js doesn’t control the test JavaScript environment (that’s controlled by Jest or Mocha or Ava) like it does for development and production modes.

My ideal API would be something like:

declare function createNextTestServer(dir: string): (req: http.IncomingMessage, res: http.ServerResponse) => void;

I’d also be happy with:

declare function createNextPageMiddleware(path: string, module: any): (req: http.IncomingMessage, res: http.ServerResponse, next: (error?: Error) => void) => void;

// Example usage
import * as SignInPage from '~/pages/[id]/sign-in';
createNextPageMiddleware('/[id]/sign-in', SignInPage);

Describe alternatives you've considered

• Looks like Next.js integration tests run next dev. Could do something similar, but code is running in a different process and would need to share one server across multiple tests to reduce compilation time. (Reduces test isolation)
• Explored calling renderToHTML or new Server from Next.js internals directly. After trying for a bit looks like these methods expect build information.
• Set up integration testing with Cypress or another tool and run next build + next start to test. This is heavy handed and can reduce test iteration speed for any HTTP tests.
• Creating a mock that calls getServerSideProps and the component in a similar order to Next.js. I would prefer testing directly with Next.js, though.

[kmjennison]

For testing API routes and some middleware, I like the approach this module takes:
https://github.com/Xunnamius/next-test-api-route-handler

It doesn't currently address everything this feature request is looking for, though (e.g., you'd still have to construct a mock ctx argument for getServerSideProps).