The tests pass but the code is broken. Do my tests test anything?

A test tests something only if it fails when the behavior it protects is broken. Coverage says which lines ran and nothing about whether an assertion would go red. Break the behavior on purpose in a scratch copy, run the one test that claims to cover it, and keep the receipt.

Why a green suite can lie.

A test can run every line and check nothing. It can expect whatever the code returned. It can exercise the neighbour of the behavior in its name.

The shape is worse when the same session wrote the code and the test, which is now the normal case with coding agents: the assertion is derived from the implementation, so a bug in the logic becomes the expected value.

three shapes of a hollow testIllustration

Executes, asserts nothing
```
render(page);
// no expect
```
passes · every line covered, nothing checked
Asserts what the code returned
```
expect(fee(100)).toBe(101);
```
passes · the bug became the expected value
Tests the neighbour
```
expect(allowed("admin")).toBe(true);
```
passes · the guest path is never exercised

Illustrative snippets. All three count toward coverage.

The deliberate break.

Change the code so the behavior is wrong, and see whether a test objects. In Closure’s vocabulary that is a negative control.

Here is the smallest case, recorded from the tutorial the engine ships with. A test named protects administrator actions passes. The engine swaps Boolean(role) for true in an isolated copy and runs the same test again. For a critical requirement, a passing test is not admissible without this.

closure verify-control · TUTORIAL.AUTHORIZATION.ROLE.001Recorded · 2026-10-11

as written
protects administrator actionspasses
```
export const allowed = role => Boolean(role);
```

perturbed · unconditional-access

- export const allowed = role => Boolean(role);
+ export const allowed = role => true;

rerun
protects administrator actionsstill passes
NOT VERIFIED · vacuous

repaired guard and test

+ export const allowed = role => role === "admin";
+ assert.equal(allowed("guest"), false);

rerun, perturbed
protects administrator actionsfails
HARNESS VERIFIED
release-check
RELEASE(closure-tutorial) = BLOCKEDRELEASE(closure-tutorial) = READY

Recorded from closure demo as shipped, then with its solution applied, engine 0.2.2. Full output

Per requirement, not per file.

Mutation testing tools do this across a codebase and report a score. It is a useful health number and the wrong unit for the question you are asking.

A 70 percent score for a file says nothing about whether the one test guarding invitation expiry would notice the expiry check being removed. Closure attaches the control to the requirement: each obligation names the test that claims to prove it and the perturbation that must make it fail, and the result expires when the code under it changes.

one number for the file, or one receipt per requirementIllustration

invitations.ts · mutation score

70%

Which 30 percent? The score cannot say.

ACCEPT.010expired link rejectedcontrol verified
ACCEPT.011revoked link rejectedcontrol refused
ACCEPT.012second accept makes no second membershipcontrol verified
SEAT.010seat limit refuses acceptanceno control yet

The requirement ids are the catalog's; the states are illustrative.

A real receipt.

The engine is measured with itself. This is one of its own controls, on the obligation that drift detection must report a capability the code performs and the selection does not cover.

The receipt names the subject digest the control was verified against. When the engine’s own sources change, that digest no longer matches, the receipt is stale, and the obligation it backs stops counting until the control is re-verified. That keeps “the test would catch it” a statement about the current code.

closure verify-control · 10f89945Recorded · 2026-10-12

perturbation: guard.force_true
edit: src/drift.ts
- if (hits.length === 0) continue; + if (true) continue;
test: test/drift.test.tsdrift detection raises a capability the code performs and the selection does not cover
verified: HARNESS 2026-10-12T03:22:08.552Z
subject: sha256:224dc76158a8f0d2191bbfdcac6261906d79ce743f4685c98293bc67b194b25d

From the engine's committed control declarations and the receipt its harness wrote. Note on the declaration: “Re-aimed by hand. The search proposed a directory-skip flip in the file walker, which blinds the detector rather than silencing it. The guarantee is that observed behaviour is reported; this drops every finding after it was observed.”

What this does not establish

A negative control proves a test is sensitive to one named failure. It does not prove the test is correct in every respect, and it does not find failures nobody declared. A requirement with no test is still unproven, and the engine reports it as such rather than inferring one. The control also cannot run when the perturbed program fails to compile; the engine’s execution receipts distinguish that incomplete run from a real failure, so a build error is never counted as a caught bug.