Requirements are all confirmed but much of the code never runs — what does a requirement-confirmed figure miss?
answer
- Its denominator has no term for code
- Failure and compatibility paths live outside agreements
- One easy check still counts as confirmed
- More link rigour cannot close this
- Triage the dark regions, do not target them
basics
~20 sIt misses everything not on the agreed list. Failure paths, defensive branches, compatibility code and residue from removed features are in no requirement, so no value of that figure reports them. Only the code-side denominator contains them.
solid answer
~50 sThe requirement-confirmed figure divides by agreed behaviour, so code that no requirement describes is not in its denominator and no value of the figure — a hundred per cent included — says anything about it. That is structural rather than a discipline problem: the denominator has no term for code, so no amount of link rigour can make it report unexercised code. What hides there is consistent between products: timeout and retry handling, guards and range clamps, readers for an older stored format, operator entry points, and leftovers of removed features. A second cause gives the same picture — one easy check per requirement confirms each behaviour while leaving most of its branches unrun. The code-side figure is the only one of the pair that points at these regions, and the response is triage: state the behaviour, accept it explicitly, delete the residue, or deepen a shallow check.
code
pseudocode · 7 lines// every agreed requirement has one passing check
verifiedRatio = 12 / 12 // 1.00
codeExercised = [happyPathRoutes]
codeUnexercised = [retryAfterTimeout, partialWriteRollback,
permissionDeniedBranch, legacyFormatReader]
executedRatio = 0.58go deeper
Recall that the requirement-side figure only counts behaviour somebody wrote down, so code nobody asked for is outside it entirely. Naming one example, such as retry handling, is enough here.
Explain why this is structural rather than a discipline gap, and list where unexercised code usually lives: failure and retry paths, guards, compatibility readers, operator entry points, residue.
Demonstrate the triage rather than a target — which dark regions become new agreed behaviour, which are accepted explicitly, which get deleted, and which are shallow confirmations to deepen.
Own the argument that a wide divergence between the two figures is a claim about the system's scope, and be ready to decide how much unstated behaviour a product should carry deliberately.
The requirement-verified figure divides by a list of agreed behaviour. Whatever is not on that list is not in its denominator, so no value of the figure — a hundred per cent included — says anything about it. This is not a gap in rigour that better link discipline could close. It is structural: the denominator has no term for code, so the figure has no way to report code that nothing exercises. Only a figure whose denominator *is* the codebase can do that, and that is the code-executed one. That leaves a specific, common and unpleasant state: every agreed requirement has something confirming it, everything passes, and a large part of what actually runs in production has never been executed by a test. ## Where the unexercised code usually is The regions that no requirement describes are remarkably consistent between products: - **Failure and recovery paths.** What happens when a call times out, a write half-succeeds, a dependency answers slowly or a retry runs out of attempts. Requirements describe success; failure handling is invented by engineers. - **Defensive branches.** Null and empty guards, range clamps, and the branch that fires only when an invariant somebody assumed is violated. - **Compatibility and migration code.** Readers for an older stored format, conversion routines kept for one release, flags that switch behaviour for existing records. - **Operator and support paths.** Diagnostic output, manual re-run entry points, back-office corrections — real behaviour that no customer-facing requirement mentions. - **Residue.** Code left behind when a feature was removed, and copies of a routine that diverged. | Code region | Why no requirement names it | What the code-executed figure shows | | --- | --- | --- | | Timeout and retry handling | requirements describe success | never reached by any run | | Guards and range clamps | written defensively by engineers | reached only on odd inputs | | Old-format readers | belong to a past agreement | dark, and possibly deletable | | Operator entry points | not customer-facing | dark, and often the riskiest | | Removed feature's leftovers | agreement withdrawn, code kept | dark: delete rather than test | A second cause produces the same picture without any unrequested code at all: **one easy check per requirement**. If each agreed behaviour is confirmed by a single run down its simplest route, the requirement-verified figure reaches one hundred per cent while most of the branches implementing those behaviours stay unexecuted. The requirement side counts *whether* a behaviour is confirmed, not *how much of its implementation* the confirmation reached. ## Reading the two together The code-executed figure is the only one of the pair that can answer "does something exist here that nothing exercises?", and it answers it bluntly, by pointing at regions. The right follow-up is a triage rather than a target, because unexercised code is not one problem: 1. **Real behaviour nobody wrote down.** The requirement list is incomplete. Add the behaviour to the agreement — the failure path *is* a requirement — and confirm it. 2. **Real behaviour, deliberately unstated and low risk.** Accept it explicitly, so the next reader knows it was a decision rather than an oversight. 3. **Code that should not exist.** Deleting it improves both figures honestly and removes the maintenance and the risk at once. Unexercised residue is the cheapest cleanup in any codebase. 4. **A shallow confirmation.** The behaviour is agreed and confirmed on paper; the confirmation just never goes near the interesting branches. Deepen the check rather than adding a new requirement. Notice that only the fourth is a testing problem in the narrow sense; the first and third are gaps in the agreement and in housekeeping. That is why the figure is a prompt for a conversation, not a target to hit — pushing it up by writing checks for residue is worse than deleting the residue. ## The habit this leaves you with Quote both figures with their denominators every time, and treat a wide divergence between them as the thing to explain. A hundred per cent of requirements confirmed alongside a low share of code executed is a claim that the system does much more than anyone asked for, and someone should say out loud whether that is retry logic worth keeping, an operator path worth confirming, or three years of residue worth removing. The pair asked together produces that conversation; either one alone lets the team believe the more comfortable half of it.
- Is unexercised code always a testing gap?No, and treating it as one leads to writing checks for code that should be deleted. Triage it: real behaviour nobody wrote down should be added to the agreement and confirmed; low-risk unstated behaviour can be accepted explicitly; residue from a removed feature should be deleted, which improves both figures honestly; and a shallow confirmation should be deepened rather than replaced by a new requirement.
- How can every requirement be confirmed while most branches implementing them stay unrun?Because the requirement side counts whether a behaviour is confirmed, not how much of its implementation the confirmation reached. One run down the simplest route marks the requirement confirmed and never touches the error handling, the retry, or the guard clauses beneath it. The code-side figure is what exposes that difference.
- Could a more complete agreed requirement list close this gap?No. Even a perfect list describes wanted behaviour, while much of what actually runs — retry handling, guards, compatibility readers — is invented by engineers to make that behaviour work. Those are implementation consequences rather than agreements, so they stay outside the requirement denominator however detailed the list becomes. The code-side figure remains the only one that can report them.
saying these in an interview costs you the question
- Assumes full requirement confirmation means the code is fully exercised
- Calls every unexercised region dead code without checking
- Thinks tighter link discipline would surface unexercised branches
- Ignores failure and fallback paths because no requirement mentions them
- Treats one passing check per requirement as thorough confirmation