Every story we ship comes with its own tests, and every new or touched line of code is covered. Not because a policy says so, but because we've felt what happens without it: a fix in one corner of the app quietly breaks another, and nobody notices until a customer does.
The rule is simple
100% coverage on new and touched code, enforced by the test runner itself — not a checklist a reviewer might skip on a busy day. If the coverage threshold isn't met, the build fails. There's no negotiating with a red pipeline.
Here's roughly what that looks like in a Vitest config:
export default defineConfig({
test: {
coverage: {
thresholds: {
perFile: true,
lines: 100,
functions: 100,
branches: 100,
statements: 100,
},
},
},
});
Why per-file, not just project-wide
A project-wide average can hide a completely untested file behind a handful of well-tested ones. Per-file thresholds mean every single file that ships has to earn its place — including the one you almost forgot to write a test for.
What this buys us
- Refactors we're actually willing to do, because a passing suite means we didn't quietly break something three features away.
- Bugs caught before a human ever sees them, not after a customer reports one.
- Code reviews that focus on design and intent, not on chasing down whether the happy path was tested.
None of this makes bugs impossible. It just means the ones that get through are the interesting ones — the ones tests genuinely couldn't have caught — instead of the ones a five-minute test would have.