Quality as a System: Coverage, Central Packages, and a Real Bug

Photo: Burst · StockSnap (CC0 1.0), via Openverse

Quality was never a matter of lacking good intentions at Xircuit. There were always tests, always reviews, always the care that handling health data demands. What was missing was something more uncomfortable: a system that decouples good intentions from the mood of the day. A net that doesn't depend on whether I happen to remember, on a tired Friday evening, to still cover that last branch.

This week was exactly about that — quality not as an intention, but as mechanics. A test coverage program that no longer asks, but demands. A package management setup that prevents two projects from secretly pulling different versions of the same library. And, almost as a reward for the effort, a real production bug that this new net found for itself the moment it was stretched out. That's the best kind of confirmation there is: not a green checkmark, but a red one that was justified.

From "we test" to "it must be covered"

The decisive step in this phase wasn't a new test, but a new rule. Until now, test coverage was a metric you observed — a number on the side that you noted and then still overlooked when things had to move fast. This week's coverage program instead pulled a coverage gate over every non-exempt assembly and switched it to enforce. The difference between "observe" and "enforce" is the whole point: from now on, the build breaks if a component's coverage falls below its agreed threshold.

That sounds strict, and it's meant to. A gate you can override with a comment isn't a gate, it's a suggestion. But what mattered to me just as much was the other side of that same coin: the exceptions. Not every assembly can be meaningfully trimmed to the same number — pure platform bindings, generated site templates, or thin wrappers around third-party SDKs are explicitly exempt, so the number stays honest instead of being inflated by alibi tests. A gate is only worth as much as the credibility of what it measures.

Where coverage really matters

Not all code carries equal risk, and that's why the work concentrated where a bug hurts the most. The Auth0 seam — the point where all sign-in and authorization docks into the identity provider — reached 100 percent coverage. This is the kind of code where a silent regression doesn't mean "a page looks weird," it means "someone gets in who shouldn't," or the reverse. Seams like that deserve the full number.

The same held for payments, which are now covered almost completely. Money flows don't forgive carelessness: a mishandled webhook, a double-booked amount, a subscription that keeps running after cancellation — these aren't cosmetic problems, they're breaches of trust. And because Xircuit renders a lot in the browser, the shared UI got noticeably more coverage through additional bUnit tests. bUnit renders Blazor components in a real component context and can be fed clicks and input, rather than just checking the logic behind them. That moves the check closer to what a person actually sees and touches.

Photo: Markus Spiske · Rawpixel (CC0 1.0), via Openverse

A real bug, found while stretching the net

The nicest moment of the week was a failure. While expanding coverage — that is, exactly when the new tests played through paths for the first time that nobody had automatically probed before — a real production bug surfaced: five medical dialogs failed to save on hosts without a UTC time zone. On my machine and in previous runs, everything had been green, because the time zone there happened to line up. Only when a test deliberately set the environment differently did the issue break open.

Bugs like this are among the trickiest of all, because they depend on the environment and not on the code alone. "Works on my machine" isn't reassurance here, it's the actual trap: a timestamp that looks correct locally tips into an invalid state on a host with a different time zone, and a save operation the user thinks succeeded runs into the void — about the most unpleasant place for that to happen with medical data. The bug is fixed now, and the lesson from it is more fundamental than the individual fix: time internally must be consistently computed in UTC and only translated into the local zone at the surface, never the other way around. That it was precisely the coverage expansion that brought this bug to light is the best proof that the effort pays off.

Order in the machine room: central package management

Alongside the test net, a cleanup job ran that you never see from the outside and yet constantly feel in day-to-day work: unifying dependencies through Central Package Management (CPM). In a solution made up of many projects, it otherwise happens gradually that two components pull different versions of the same library — one here, one there — and eventually the same package behaves differently in two places. CPM pulls all version declarations into a single, central location. From now on there is one truth about which version of what is in use.

Two further building blocks go with it that together round out the picture. MinVer provides tag-driven versioning: a build's version number derives directly from the Git tag, not from a manually maintained number in some file that regularly gets forgotten at release time. And targeted security pins close known advisories — wherever a transitive dependency brings along a reported vulnerability, the affected version is deliberately pinned to a safe one instead of hoping nothing happens. This is unglamorous hygiene, but it's the kind of hygiene that makes the difference between a codebase you understand and one you merely administer.

The same scenario, live and local

A test net is only as good as its closeness to reality, and that's why this phase was also about bringing the tests closer to real operations. This included prod E2E interaction mutations — end-to-end tests that no longer just call up and look at pages, but deliberately change state: create something, rewrite it, clean it back up, and along the way check whether the chain really holds. A test that only reads finds half the bugs; only one that writes runs into the edges where the interplay snags.

The building block I rely on most here is a shared scenario library that runs the same scenario live and locally. Instead of maintaining two separate test worlds — one against running production, one against the local development environment — a scenario is described once and run in both worlds. That doesn't just save work, it rules out an entire class of bugs: the quiet drift between "this is how we test locally" and "this is how it actually behaves." When both sides run through the same flow, one can no longer drift away from the other without it being noticed immediately.

Why this week felt different

It wasn't a week with a shiny new feature to show off. No new screen, no feature to click on. And yet it was one of the more reassuring stretches in a long time, because something fundamental shifted beneath the surface: quality now depends less on my mood that day and more on a mechanism that kicks in even when I'm in a hurry. An enforced coverage gate, a tidied-up package world, and a test net that proved its worth the very same day it was created — that's exactly the kind of invisible work that carries a platform instead of merely decorating it.

What's next?

Next week it gets more visible again: a marketing matrix of 209 industry feature pages, a partner system, and a new about page. After these days in the machine room, I'm looking forward to building something you can see and touch again — on a foundation that now noticeably carries more weight.