The anchor post of the mutation-testing series. What mutation testing actually measures, why it exists as a complement to line coverage, when to reach for it, and the specific classes of test-suite weakness it uncovers — written to stand alone regardless of your language.
Unit tests that break every time you refactor are describing the implementation, not the behavior. A senior engineer’s playbook for writing black-box tests that survive.
Four voices argue about unit tests. The debate dissolves once you separate coverage-as-target from coverage-as-detector, with testability as the real prize.
Years ago, on my first day at a new company, I sat down for what I thought was going to be a normal pair-programming session. There was a story on the board — I no longer remember what it was, exactly. Some feature, a handful of requirements, the usual shape of a first ticket at a new job. I read the requirements, my mind raced ahead to how I’d build it, and I started talking through my approach. ...
Most of the debate around test-first development gets stuck on process — red-green-refactor, coverage percentages, whether it slows you down on day one. That debate misses a simpler, more concrete effect, and you don’t need to know Go, or even know how to code, to follow it: Whichever thing you write second has to bend to fit whatever you wrote first. Write the code first and the test second, and the test has no choice but to accommodate whatever the code already does — however it talks to the database, however it calls the network, however it happens to be built. Write the test first, and it’s the code’s turn to bend: it has to be built in whatever shape lets the test — which doesn’t have a real database or a real network sitting around — actually run. That’s the entire mechanism. Nothing about willpower, experience, or caring more. Just: which one existed first gets to set the terms. ...