GNOME — Gap Narrowing & Observability Model Engine
Close the gap — and prove the test works.
When a change lands on code your suite never exercised, GNOME turns that gap into tests, then mutates the code to prove each test actually detects a failure.
The loop
Target the gap
Start from the uncovered lines SCOPE named.
Author tests
Write a test aimed at each gap.
Confirm coverage
Prove the test actually reaches its target line.
Prove it detects
Inject a fault — the test must fail.
Verified only
Passes and kills the mutant, or it is discarded.
Coverage tools stop at VALIDATE. MUTATE is the step that makes the difference.
Mutation is the proof
A test that passes tells you very little. The question that matters is whether it would still pass if the code were wrong.
So GNOME breaks the code on purpose. It inverts a condition, alters a boundary, changes an operator — and then re-runs the candidate test. A test that stays green against deliberately broken code cannot tell a working build from a broken one, and is rejected. Only tests that catch the injected fault are kept.
This is the step that separates verified coverage from coverage that merely looks good on a dashboard.
A proven test, or an honest answer
GNOME does not always succeed, and it does not pretend otherwise. Every gap it handles ends in one of two places: a mutation-proven test, or a structured explanation of why it could not produce one — the existing tests were inadequate, the mutation was equivalent to the original, the code itself has a defect, or the behaviour is simply not implemented yet.
What reaches the gate
- What is proven — the tests that are mutation-verified to catch a real fault.
- What was checked — the coverage map for every executable line in the gap.
- What remains unverified — reported explicitly, including lines that are not executable at all. Nothing is hidden to make the number look better.
- The audit trail — mutation results, coverage map and decisions, recorded per change.