Why we publish our own test-to-production ratio in public

"Thoroughly tested" is one of the least verifiable claims in software marketing, because it is almost never accompanied by a number. We'd rather give you the number and let you judge it than ask you to trust the adjective.

The Nexus repository's README carries a project-status dashboard, generated automatically from the codebase rather than written by hand, that tracks total lines of code, production lines of code, and dedicated test-code lines, and computes a test-to-production ratio from them. As of this writing that's roughly 10.8k lines of dedicated automated-test code against the production codebase — a number that updates itself as the platform grows, instead of a "fully tested!" badge nobody can check.

What this number is — and isn't

• It is a real, automatically-computed ratio, not a marketing estimate — the same script that classifies test files from production files runs against every change.
• It is a floor, not a ceiling: two required suites (a unit/integration suite and a separate multi-tenant isolation suite) have to stay green before anything merges to main, on top of dependency-audit and secret-scanning checks in CI.
• It does not mean every possible bug is caught — no test ratio does. It means the coverage claim is a number you can watch move over time, not a claim you have to take once and never revisit.

We treat this the same way we treat feature status: publish the real number, let it be occasionally unflattering, and let it improve visibly instead of only in private. If a competitor's pitch includes "enterprise-grade testing" with no further detail, that absence of a number is itself information.

This is also the standard behind the module status labels across the platform pages — a module doesn't get marked further along because a demo looks convincing; it moves when the tests and the real wiring behind it do.