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.

Choose your tickets