When it comes to testing library code, the (usually amazing!) "Testing Library" approach quickly hits its limitations: We often need to test hot code paths to ensure additional guarantees, such as a specific order of DOM changes or a particular number of renders.
As soon as we start adding Suspense to the picture, it even gets almost philosophical:
How do we count a render that immediately suspended, and how do we distinguish it from a "committed" render?
How do we know which parts of the Component tree rerendered?
In the Apollo Client code base, we're using the React Profiler to create a stream of render events, enabling us to switch to a new stream-based testing method.
After testing this approach internally for a year, we have released it in a library that we want to present to the world.
I'll also briefly look into other "testing-related" problems far outside the norm that we've come across and share our solutions:
How to test libraries that bundle different code for React Server Components, streaming SSR runs, and the Browser: Testing your growingly complex `exports` fields and ensuring all those environments export the package shape you expect.
We'll even briefly look into rendering React components in different environments to test them in isolation - be it in Server Components, Streaming SSR, or simulating stream hydration in the Browser.
This talk has been presented at React Day Berlin 2024, check out the latest edition of this React Conference.
