Tests are documentation that runs

A comment can lie. A README can describe a system that no longer exists. A test suite cannot drift the same way, because the moment it stops matching the code, it fails. That single property makes it the only documentation you can trust without also checking the date it was last edited.

Prose goes stale silently

Nothing forces a comment or a design doc to stay accurate. The code changes, the writer moves on, and the words sit there looking authoritative while being wrong. Nobody gets an error message when a README falls out of sync. You just find out later, usually while debugging something the doc told you was impossible.

A test either runs or it tells on itself

A test makes a claim and then checks it, every time you run the suite. If the claim stops being true, the test goes red. That feedback loop is the whole advantage: staleness turns into a failure you cannot ignore, instead of a wrong sentence you never notice.

Naming and structure matter more than usual

If a test suite is meant to be read, not just executed, it has to be written for a reader. Name the test after the behavior it guarantees, not the function it happens to call. Group tests by scenario, not by implementation detail. A suite full of `test1`, `test2`, and mocked-everything setup documents nothing, even though it still passes.

Where the analogy breaks down

Tests document what the code does, not why it does it, and they say nothing about the paths not covered. A green suite can still leave you guessing at intent, at rejected alternatives, at the tradeoff behind a weird-looking line. Tests are necessary documentation, not sufficient. You still need prose for the decisions that never show up as assertions.