My Testing Philosophy: Where I Actually Draw the Line
No test suite religion here. Some code gets tested obsessively, some gets none at all, and the line between them isn't about coverage percentages — it's about what actually breaks quietly.
Ask ten developers about testing and you'll get ten different orthodoxies — test everything, test-driven development as the only real discipline, coverage percentages as a proxy for quality. As a solo studio running six products, I don't have the headcount to follow any of those orthodoxies consistently, and I've stopped trying to. What I actually do is test unevenly, on purpose, and I want to explain where the line actually is instead of pretending I have a uniform policy I don't.
What Gets Tested Obsessively
Anything touching money. Billing logic, subscription state, anything that determines what a user gets charged or refunded. This is the one category where I write tests before I'm confident, not after, because the failure mode isn't a bug report — it's a support conversation I don't want to have and a trust problem that doesn't fully repair itself.
Anything with a silent failure mode. Code that can fail in a way that produces a plausible-looking wrong result instead of an obvious crash gets tested heavily, because that's exactly the category of bug that survives in production the longest. A crash gets reported immediately. A quietly wrong number gets discovered weeks later, if at all, and by then it's harder to trust anything downstream of it.
Anything shared across products. Code that multiple apps depend on gets tested more than product-specific code, because a bug there doesn't cost me once — it costs me once per product that depends on it, and the blast radius of getting it wrong scales with how many things break at the same time.
What Gets Little to No Testing
UI polish and one-off scripts. A one-time migration script, a small internal tool, a UI tweak with no state logic behind it — these get eyeballed, not tested, because the cost of writing a test exceeds the cost of the thing occasionally being visibly, obviously wrong. Visibly wrong is cheap. It gets noticed and fixed fast, precisely because it's not silent.
Anything I expect to throw away. Early-stage exploration code, a rough version of a feature I'm not sure will survive contact with real usage — testing this thoroughly is testing something that might not exist in a week. I'd rather find out fast whether the idea holds up than invest test infrastructure in code that's genuinely disposable.
Front-end rendering details that are obvious on sight. If a bug in this category ships, I see it, or a user sees it and tells me immediately, because it's visually broken. The class of bug that testing exists to prevent — the one nobody notices until it's caused real damage — doesn't really apply here.
The Actual Filter
The real question I ask isn't "is this important" — almost everything I ship feels important in the moment I'm shipping it. It's "if this breaks, will anyone notice before it costs something." Money logic and silent failures fail that test badly — nobody notices until real damage is done. Visual bugs and disposable code pass it easily — the failure is loud, fast, and cheap to fix. That's the actual line, and it's a better filter than any coverage percentage, because coverage percentage treats a payment calculation and a button's hover state as the same category of risk, and they aren't.
Why I Don't Feel Bad About the Uneven Coverage
I used to feel a low-grade guilt about not having uniform test coverage across the codebase, like it was a discipline failure I hadn't gotten around to fixing. I don't anymore, because uniform coverage was never actually the goal — the goal was catching the bugs that would have actually cost something, and a test suite that treats every line of code as equally risky is spending effort in the wrong place just as often as it's spending it in the right one.
The Bottom Line
Six products, one person, no QA team — uneven testing isn't a shortcut I'm taking under pressure. It's the actual strategy: heavy coverage where failure is silent and expensive, almost none where failure is loud and cheap. That's not a lower bar than "test everything." It's a different bar, aimed at the thing testing is actually supposed to prevent.