Repository: react
Issue: Feature request: Expose additional profiling tools for library testing
Labels: Type: Discussion

Hi there!
I did bring this up recently in a tangentially-related PR discussion, and @sebmarkbage pointed out that this would do better as it's own issue, so here goes :)

We found that for testing a library, the "eventual consistency" style of RTL-testing doesn't really work, and we need different tools.

While the test is waiting for a consistent result, we could inadvertedly rerender 20 times with inconsistent return values in-between, and our tests wouldn't catch it.
While that is usually fine in UIs, having that happen in a library... well, every single accidental rerender we perform trickles down to thousands of applications, and an inconsistent render would cause tons of userland bugs.

So, as a result, most of our newer tests use the <Profiler> component and every time a React render happened, we take a snapshot - depending of the test, we sometimes snapshot a DOM, sometimes we snapshot hook return values, sometimes other things.

Especially in our Suspense hooks tests, it has been proven invaluable that we also track which components actively participated in a specific render. Tracking those is a bit fiddly at the moment, but we make do. (Keep in mind, we're testing a hook library, so every test defines a bunch of components and then we test how they interact - we can just add something like useTrackRender() to each component.)
Then, our tests consume all these snapshots in an async-iterator-like pattern, so we can make assumptions on every single render.

Examples on how those tests look:

* https://github.com/apollographql/apollo-client/blob/25ff067b36bd4ec3833a2d71f74c8aed75e2944f/src/react/hooks/__tests__/useQuery.test.tsx#L5187-L5216
* https://github.com/apollographql/apollo-client/blob/6b39e3f19ba0944b38c8b2822945dc7ca847731c/src/react/hooks/__tests__/useSuspenseQuery.test.tsx#L361-L415
* https://github.com/apollographql/apollo-client/blob/6b39e3f19ba0944b38c8b2822945dc7ca847731c/src/react/hooks/__tests__/useLoadableQuery.test.tsx#L307-L356

 
Just to be clear again: we know that we're very close to "testing implementation details" with something like that, and I'd never recommend anyone to test an actual application like that. But for a library, this style of testing is an amazing tool - and we're fine with the drawback that we have some tests that have to test for different "correct" behaviour depending on the React version we're testing against.

Since you are currently adding more apis to access internals like stack traces during testing, I was wondering if it would be a good time to ask for additional Profiler tooling.
Right now, it is next to impossible for any tooling except for the React Devtools to get the information of a Profiler recording (there are too many internals involved, and on top of that, a lot of interprocess communication that would not be necessary in a testing scenario) - but for us, getting that data would be invaluable for that style of testing.

Could we get something like a `react-dom/test` `renderWithProfilerRecording` (or even better, `renderToProfilerIterator`) API?

Getting information like
* how many rerenders happened
* which components caused which rerender
* which components participated in which rerender

 would be incredibly powerful to guarantee an optimal library experience.