Mocking useHistory breaks CompatRouter in tests

[iAmNathanJ]

I'm looking into migrating a very large codebase from v5 to v6. We'll be using the compat package. We have many tests that make assertions against history methods being called. They go something like this:

// ceremony
jest.mock('react-router-dom', () => ({
  useHistory: jest.fn()
}));

const {useHistoryMock} = jest.requireMock('react-router-dom');

const pushSpy = jest.fn();

useHistoryMock.mockReturnValue({push: pushSpy});
// end ceremony

describe('<Thing />', () => {
  it('calls history.push', () => {
    render(<Thing />);

    // do whatever

    expect(pushSpy).toHaveBeenCalledWith('/some/path', {maybe: 'some-state'})
  });
});

I realize we will no longer access history directly and so all of our tests written around that will need to change. To complete the migration incrementally, I had assumed we would need to render <CompatRouter> in tests and they would at least run while we migrate. But the code above will cause CompatRouter to throw - if I understand correctly, useHistory is the glue between the internal v6 instance and the consumer's v5 instance within the compat package.

Is there any formal guidance on how to deal with this kind of scenario?

I think a couple options are:

• Shim our mock useHistory to satisfy the needs of CompatRouter. But that would add more to the ceremony in every test that applies. Not a very appealing option.
• Maybe expose the router location and focus our test assertions on that as a side effect of performing navigation?
• Maybe a custom jest resolver can force react-router-dom-v5-compat to get the unmocked module? 🤔

I'm sure there are lots of ways to arrange it, but I'd love to know if the remix team has specific thoughts for how to approach this specific case.

[alioshr]

I am currently analyzing this same thing. I jumped straight into the v6 apis as we use microfrontends so on the remote I am working on there are just a few routes, but it is quite hard to make these tests work without mocking. We should not need to mock anything, it does not sound very healthy on a testing perspective.

[lopze94]

Have you been able to find an optimal solution for this? We ran into the same issue and we just ended up wrapping useHistory. This allowed us to mock the wrapper and not useHistory directly. We just needed to update all the tests and their corresponding files that made assertions against history methods. Which I thought was going to be a big change but I finished it up in a day. It wasn't that bad. This allowed us to use a single test helper to access v5 and v6 APIs. Before we were using two helpers and developers would have to figure out which one to use. Sometimes it was hard to tell because there could be a deeply nested component using v5 APIs, but the test was wrapped in a v6 environment, making it hard to debug. It took more time to figure out why tests were failing before this than it took to update all tests and files to use the useHistoryWrapper.

[alioshr]

You should not mock react-router-dom.

You should create a history instance and observe stuff as the history.location.pathname

For instance:

const history = createMemoryHistory();

// wrap you frontend components under test with both routers, 
//reflecting the production env. We use an utility wrapper along with react testing library. 
// Then pass the history instance to the v5 Router instance, something like this:
 <Router history={history}>
        <CompatRouter>{this.children}</CompatRouter>
 </Router>

// test stuff that triggers navigation, or whatsoever
// and then make assertions like this: 
expect(history.location.pathname).toEqual(BASE_URL);

[aBOBination]

This did it for me! Thanks!