[RSC] Any advice on how to write unit tests when using server components

[jderochervlk]

I'm trying to write some unit tests using Vitest and the Storybook plugin for RSC and Vitest browser mode.

https://github.com/storybookjs/vitest-plugin-rsc

It doesn't work as the react router imports have errors around accessing client side code such as createContext. I'm assuming the react router vite plugin for RSC is changing imports somehow to make things safe for RSC, but when writing unit tests I can't (or don't know how) to use the react router plugin.

Any advice on how to do this? Ideally I want to have components live in separate packages in a monorepo with unit tests and have the actual react router site have tests with Playwright.

[Samielakkad]

The boundary you propose is the right one. React Router's RSC framework mode is still experimental and its Vite setup creates separate server/client module graphs. The Storybook RSC plugin alone does not reproduce React Router's unstable_reactRouterRSC() transforms and route-module environment, so importing a framework route module in a generic Vitest/Storybook graph can resolve the wrong entry and produce the createContext failure you are seeing.

I would split testing like this:

• Put pure domain logic and server data transformations in ordinary modules and unit-test them in a Node Vitest project.
• Put interactive leaf components behind a "use client" boundary and test those with browser Vitest or Storybook.
• Treat framework route modules, loaders/actions, RSC composition, and navigation as integration behavior. Start the app with its real Vite config (unstable_reactRouterRSC() together with the RSC plugin) and test it through Playwright.

Avoid importing the route module itself into the shared component test project. Extract the function or component you want to test and import that smaller module instead. createRoutesStub can still help for normal components that merely need router context, but React Router's testing guidance notes that it is not a substitute for framework route types and framework-level behavior.

For the monorepo, this usually means a shared package with no route-module imports, app-level Playwright tests for each assembled route, and pinned React Router/RSC plugin versions. That gives fast unit feedback while ensuring the experimental RSC transform is tested only in the environment that actually owns it.