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.
Comments