The creator of Next made an interesting Tweet about React becoming the Linux kernel of front end development. I’ll go a step further: I think it’s becoming a ubiquitous interface for UI development generally. I bet a lot on React: I use it for every UI endeavor I work on — video games, B2B, mobile apps, and websites of every shape and size.
Even though I think the future of UI development is React (or at the very least: declarative “component-style” frameworks) it’s worth mentioning that React isn’t perfect, and there are some areas that might not ever be a best-in-class experience.
One of these areas is unit testing. I find writing and maintaining React unit tests to be one of the worst experiences in modern development.
UI testing can generally be thought of as working with a big DOM-like object. Using the vanilla web API as an example, you push updates to the DOM via the likes of createElement, createTextNode, setAttribute, and then assert the state of the DOM via getElementById and querySelector.
This is a massive oversimplification, but also a good mental model for testing. You fire UI actions which update a “really big object” and you assert the “really big object” is displaying the correct data.
But React is a different ball game. Changes to the UI are dispatched to the renderer, which then updates the UI asynchronously. The React philosophy — perhaps the most important part of the React philosophy — is that you don’t “know” when the state has updated. You can only write the React component to handle re-renders — the renderer “tells” you when the state has updated by re-rendering the component.
Because of this, interacting with the UI within the testing environment feels non-deterministic. Understanding the UI state from the test becomes a challenge.
Did your button press update the UI? Maybe it did; maybe it will. Did it trigger a re-render which overrode the intermediary UI you wanted to test against? Possibly. Good luck making fine-grained assertions on renders happening within milliseconds of each other. Test utilities like act and waitFor are bandaids — the test basically reads: “eventually something will happen!”
This is a problem for maintenance too. Insignificant UI changes can easily cause regressions, even when it is indiscernible to the user. Added an animation delay? Indirected the interaction through another piece of state? Changed a call order so a mutation happens earlier/later? You may find yourself modifying the sequencing of dozens of existing tests.
Every React shop I’ve worked at — all in all a hundred developers — has had a litany of bandaids to work around testing behavior. Waiting for the event loop to drain, mocking InteractionManager, sleeping, manually triggering re-renders — this is all cope.
Frankly, this problem occurs with any sufficiently complex asynchronous UI. But it seems like the development community has committed to this asynchronous, declarative mental model of UI — a mental model which does have downsides, and is certainly not how humans naturally think about user interfaces.
So how do we make this better? I don’t really know.
It feels like a philosophical impasse. Tests must be written procedurally: a step-by-step description of an interaction; meanwhile React is written declaratively: a description of how to react to certain types of data. Declarative code that is executed via a renderer is very bad at describing things with chronological precision, and vice versa.
SwiftUI provides an interesting alternative which can be emulated in React, albeit poorly. House all of your stateful logic in a class based view model, and then write tests against the view model — ignoring the UI except perhaps to assert non-interactive states. The view model can house complex interactivity and be tested as a state machine while avoiding non-deterministic smells of fighting the renderer.
This isn’t a bulletproof solution — it divides the CUTs, and doesn’t meaningfully test the boundaries. But perhaps that is best reserved for QA testing suites anyway.
I think in the future, perhaps leveraging AI, we find ourselves abstracted away from writing UIs directly. Leveraging tools like Figma or Xcode’s Interface Builder, we may not find ourselves managing the UIs at all, instead working on a higher abstraction layer allowing us to focus on actions and events as they pertain to user interactions. Sufficiently well architected React apps almost do this already. Once the declarative ‘problem’ is solved, developers can go back to worrying about the interactions in terms of natural, procedural thinking. And writing tests against procedural code is much, much easier.