Access the location object of a memory router for testing purposes

[silvenon]

I wasn't able to find this in the docs, so I managed to find it in the source code. I was writing unit tests using createMemoryRouter and wanted to check whether expected search params have been added. I noticed that I can reach the router's location object through router's state property:

import { render ) from '@testing-library/react'
import { createMemoryRouter, RouterProvider } from 'react-router-dom'
import { routes } from '../routes'

test('check search params', () => {
  const router = createMemoryRouter(routes)
  render(<RouterProvider router={router} />)
  // ...
  expect(router.state.location.search).toBe('?foo=bar')
})

Usually you'd want to test the impact of your search params, rather than the params themselves, but in my case I wanted to check one of the search params just to be sure.

Let me know if there is a better way to do this, and whether accessing the state property is fine. Until then, this works 💯

EDIT: To avoid using the low-level state property, a good alternative is to use useLocation() in a pathless layout route: #11200 (reply in thread)

[brophdawg11]

yeah, router.state is fine for unit tests. It's not usually an API we expect folks to use in their apps and you should be using useLocation there. And technically you can do that in your unit tests and render a component that renders the value of useLocation and assert against the rendered HTML - but it's often a bit easier to just assert against the router state.

[silvenon]

I also feel like router.state is not what I should be using because it's not documented, could you give me an example of using useLocation() to make such an assertion? 🙏 (I'm using VItest)

The only thing that comes to mind is mocking my route component to wrap it in a container component… but that seems like such a lot of work…

[brophdawg11]

It's documented on the router README: https://github.com/remix-run/react-router/tree/main/packages/router#api

Usually you'd want to test the impact of your search params, rather than the params themselves

I agree with this. I think the best test you could write is to assert that your component, as-is, renders the proper UI in response to the new search param. Just testing the location updating is, to an extent, testing implementation details of the router. When I click a link it updates the location. But that does not test that your UI properly updates in response to that change.

could you give me an example of using useLocation() to make such an assertion?

You just render the output in a component somewhere and assert against the HTML: https://github.com/remix-run/react-router/blob/main/packages/react-router/__tests__/useLocation-test.tsx#L5

I don't think a wrapper is a bad solution for a test. I'd probably put it in a pathless layout route around the whole app and then the rendered useLocation is always available.

test('check search params', () => {
  const router = createMemoryRouter([{
    path: '',
    Component() {
      let location = useLocation();
      return (
        <>
          <pre data-location>{locatyion.pathname + location.search}</pre>
          <Outlet />
        </>
      );
    },
    children: routes
  }]);
  // render app, click link, whatever
  // assert that [data-location] matches the proper params
})

[silvenon]

It's documented on the router README: : https://github.com/remix-run/react-router/tree/main/packages/router#api

Thanks for the link!

I'd probably put it in a pathless layout route around the whole app and then the rendered useLocation is always available.

Great idea, this is perfect! ⭐

[silvenon]

I think the best test you could write is to assert that your component, as-is, renders the proper UI in response to the new search param. Just testing the location updating is, to an extent, testing implementation details of the router. When I click a link it updates the location. But that does not test that your UI properly updates in response to that change.

Well said, I'll definitely rewrite those tests to test results rather than location because those search params are there only to for the loader to pass them to endpoints. Instead I should mock the endpoint, return different results from the endpoint based on the search params, and finally test the result UI instead.

But I like that I have this trick to fall back on! 😌

[mukunda-]

Just sharing another tip here since I was looking into this sort of thing today on react-router v7. You can also stub out desired routes to check, and that way you can use findBy to verify ending up at a particular pathname, without having to extract the location state.

...
{
  path: "/cancelled-subscription",
  Component: () => <div>SUBSCRIPTION_CANCELLED_PAGE</div>,
},
...

await screen.findByText("SUBSCRIPTION_CANCELLED_PAGE");