How I decide what actually needs a test
Most test-coverage debates are about the wrong number. The question isn't "what percentage is tested" — it's "what breaks silently if this changes."
Here's the heuristic I actually use.
1. I test what can fail without anyone noticing.
A crash gets caught immediately — someone sees the error. The dangerous bugs are the ones that quietly return the wrong answer. That's what earns a test first.
2. I test behavior, not implementation.
If I can refactor the internals and a passing test turns red for no functional reason, the test is testing the wrong thing. It should survive a rewrite and only fail when the actual behavior changes.
3. The failure path gets as much attention as the happy path.
The empty list, the timeout, the duplicate submit, the permission that's missing. Almost nobody writes these first — and almost every real incident lives here.
4. I ask "would this test have caught the last bug like it?"
Not "is there a test." A test that passes whether the code is right or wrong is decoration, not protection.
The honest nuance: 100% coverage isn't the goal, and chasing it produces exactly the decorative tests from point 4. A smaller set of tests that would actually fail on a real regression beats a large set that wouldn't.
The real question was never "how much is tested." It's "what would I actually notice if it broke."
What's your rule for deciding something needs a test?