Rule 24 of 38 · Chapter IV — Write for the Next Developer
A test is a specification
Why this rule exists
A test says, in executable form, what the code is supposed to do. Read that way, the test suite is the clearest specification you have: it cannot drift out of date without failing, and it states behavior in concrete cases rather than vague prose. This is why a test asserting an implementation detail is worse than useless — it specifies the wrong thing and breaks on every honest refactor.
In practice
Write tests that describe behavior a user or caller would care about, and name them so the name reads as a claim about the system. Test through the public interface, not the internals, so the test survives refactoring and documents the contract. When a test fails, read it first as a spec: is the code wrong, or has the specification legitimately changed?
When it doesn't apply
Some tests exist to pin down performance, catch a specific past regression, or characterize legacy behavior you don't yet understand. Those are legitimate even when they aren't clean specifications — just don't mistake them for the contract.