6.4 data routes: components using loaders are hard to test

[tommie-lie]

The following stackblitz shows two different tests with two problems about testing data routes: https://stackblitz.com/edit/vitejs-vite-f41ped?file=src%2FApp.test.js&view=editor

The data router API itself makes testing components that rely on some external state really straightforward as we can inject different values from within the tests without any mocking (yay!). However, note that both tests pass, but the assertions are not what you expect them to be!

The first test is about waiting for the rendering to have settled when a route depends on a loader. Of course, the two first assertions are futile, it is impossible for react-router to have immediately settled or for the component to be rendered immediately after the loader has been called (in this case it might be, but generally the promise will be a network request which takes some time).
But it still feels strange to always have to await findBy... the first assertion. Especially for transitions or elements that are not supposed to be there (expect(queryBy...).not.toBeInTheDocument()) this makes tests more brittle and dependand on the order of assertions.
Is there a nicer way to wait for react-router to have settled completely and only then do assertions on the actual DOM?

The second issue is much more grave: the second test passes with the wrong data! It is supposed to display quux but the assertion for foo is true instead! When only the second test is executed or the order of the two tests in the file is reversed, it fails because now quux is in the DOM.
This root of this problem is the module-scoped singleton: react-router/lib/components.tsx#L46-L50
The first time any data router is rendered, this singleton is initialized. All further instances of any data router component use this first instance and don't refresh the routes. This will cause any subsequent tests to actually render the routes from the first test ever executed.

Of course, the internal tests use the _resetModuleScope() function, but this is not available in the dist bundle.

Is there another way to test apps that use data routes that I'm missing or should _resetModuleScope() really be part of the public interface?