Feb — Mar 2026 · Profound
Becoming the person who writes the tests
Roughly 35 pull requests over five weeks, and the largest share of the test suite.
A six-engineer team was merging around 95 commits a month into a CMS with thin regression coverage. Nobody assigned this to me. It was the most useful thing I could see to do, and doing it turned out to be the best map of the codebase I could have drawn.
What went in
- Harnesses for the parts that make testing this codebase annoying: the Supabase data layer, tRPC context, and the WASM boundary.
- Coverage by subsystem rather than by file — auth and security, API routes, server actions, block lifecycle and CRUD procedures, the renderer core, script and asset procedures.
- Tooling that reports coverage, so the number was visible to everyone instead of being something you ran locally and forgot.
The tests worth having
Not the happy paths. The highest-value tests were the ones covering failure: WASM failing to initialise, an upstream proxy returning garbage, the paths nobody exercises until production does it for them.
I also fixed a flaky lazy-load test rather than retrying it. A flaky suite is worse than a small one, because people stop reading the red.
I ended up writing about a third of all test code in the repository, more than anyone else on the team. Six months later it is still the contribution I'd defend hardest, and it's the one that shows up on no dashboard.