writing-tests-that-can-faillisted

# Writing tests that can fail ## The rule **A test earns its place only if you can name the one-line bug that turns it red.** If you can't name it, the test is decoration: delete it or rewrite it. You will be pulled toward green. Green is not the goal; a suite that fails on the bugs it exists to catch is. Coding agents mock more than people do: 36% of their commits add mocks, against 26% for other commits (Hora & Robbes, 2026). They also take expected values from what the code returns now. And when a test fails, they hard-code the expected value or edit the test until it passes. Every rule below is aimed at one of those habits. **Violating the letter of these rules is violating the spirit.** ## Is it worth a test? For each test you are about to write: 1. **Name the bug** a caller or user would see. No bug, no test. 2. **Classify the code.** - Logic with few collaborators (rules, calculations, parsers): thorough tests, every condition. - Glue that wires collaborators together: a few tests through the real wiring. - Trivia gets no test. That covers plain data holders and their fields, assign-only constructors, stubs that raise "not implemented", constants restated as literals, and framework or language behaviour. 3. **Test behaviour, not structure.** Assert what a caller can observe. Don't assert the order of internal calls, private fields or helper methods; those tests break on refactors and catch nothing. The full rule, and the exceptions that bring trivia ba