falsifiable-testslisted

# Falsifiable Tests A test that has never been seen to fail is not evidence. It is a claim about the code that has itself never been tested. Green means one of two things, and from the outside they look identical: - the behaviour is correct, or - the test cannot detect the behaviour being wrong. The job of this skill is to tell those two apart empirically, by observation rather than by reading the test and finding it convincing. Reading is how false negatives survive — a vacuous test looks exactly like a real one, which is why it got written in the first place. ## The core rule **A test counts as verification only once it has been observed red for the right reason.** Two failure modes matter, and they are not symmetric: - **False negative** — the test passes while the behaviour is broken. This is the dangerous one. It converts "we have tests" into false confidence, and it is silent. Most of what follows is aimed here. - **False positive** — the test fails while the behaviour is fine (flaky, environment- dependent, order-dependent). Loud and annoying, and it trains people to ignore red, which manufactures false negatives downstream. ## The red proof Four steps, applied to the specific test you just wrote or are auditing — not to the whole suite. **1. Green.** Run the test against correct code. It passes — and the runner's count line says it ran: `1 passed`, not `1 skipped`, `no tests ran` or `Tests run: 0`. A filter that matches nothing reports success in ev