v7 Framework SPA : is testing impossible ?

[joccd]

Hi,

I work on a new SPA project and I want to use React Router v7 (framework).
The problem is I don't see how to test my app like I used to (vitest, testing library, msw, ...).
I read this page : Testing but there are 2 problems :

• It doesn't work if my component use type-safety, I have to use useLoaderData
• It doesn't test the loader/action func

Any Idea ?

Regards,

[sergiodxa]

I think the first one is a problem many people reported, the testing helper doesn’t support components using the component props

You could create a route component that calls useLoaderData and useActionData and pass that to your own component as a prop

The second issue, the createRoutesStub is to test React components in the context of React Router

To test loaders and actions you could just call them as normal functions, you will need to pass a Request instance, a params object and a context object

Although instead of testing the loaders and actions I recommend you to test the logic inside. If you move that to another functions you don’t need to simulate a request to test them.

[msatgh]

Could you provide an example on how to use createRoutesStub with a route component and a loader (mock)? I tried a lot, but in now way can get data from the loader into the component. loaderData is always undefined. The documentation of React Router v7 is very sparse, it shows only an example with an action, but there are many more properties going into createRoutesStub. For instance if i have no HydrateFallback defined i get an error,...

[andrewjroberts]

Thanks for the summary @sergiodxa

I'm a giant fan and advocate of React Router v7 internally at my job.

IMO testing route components, loaders, and actions is the least polished part of v7 currently. There's no contributor-blessed examples or public documentation for anything beyond 101s. e.g. having a component with props in this section of the docs https://reactrouter.com/start/framework/testing -- 100% of users who opt in to recommended type safety features will face this problem

I currently just plop in some //@ts-expect-error's and call it a day, but it's something I have to constantly hand-wave over to teammates. "It's on their radar, I'm sure they'll iron out the rough edges eventually". See other thread too: #12730 (reply in thread)

It's so close to being the ultimate SPA framework, hope the testing story gets the attention it deserves eventually 🙏

[brophdawg11]

Oops! Support for the props in createRoutesStub was an oversight on our part - adding support for that here: #13528

[timfrans]

To come back to this issue, I don't think just calling loaders & actions in a test is a good way of testing your react router application.
To given an example, we've defined middleware an a "top-level" parent route which performs e.g. authorization.
You're not able to assert this when you're writing tests which simply call loaders or action. I know you should probably write tests for this top-level route so you assert authorization is performed, but I don't think this is a good way to cover authorization on other routes. There is a "decoupling" here.

I know this issue is an old issue and probably middleware didn't exist when this was created, but are there any resources which explain this further. Or any examples?

[sergiodxa]

Yeah this is before middleware.

In my experience, you shouldn't test loaders/actions directly. Test the logic, let's say you have a route that returns a single post in a loader, and in the action allow users to update it, move the logic to a getPost(id) and updatePost(id, data) and these those functions.

Loaders and actions are integration points where you read from the request, run your business logic functions, and send a response based on the result.

Your getPost or updatePost should not depend on the middleware so this makes it really easy to test. Even your middleware should call functions that don't depend on the Request or another context, so you can test in your case the authorization logic works, although I usually only put authentication in middleware and authorize in loader/actions.

Finally, if you want to test the loaders/actions too, use an integration test with something like playwright and navigate to the route, then test the page loaders (middleware + loader + component worked), fill the form and submit (component + middleware + action worked).