The First Test I'd Write in a File With None
The first test I ever wrote wasn't a choice. It was a reaction.
I was working on a booking system — reserve a slot, done. I didn't know much about testing at the time; the codebase had none, and it hadn't occurred to me that it needed any. Then, in production, two people booked the same slot at the same time. Both requests went through. Both people showed up expecting it to be theirs.
It wasn't a rare fluke — the code had no protection against it at all, so it was only a matter of time. The client was angry, and rightly so: this was the one thing the system existed to prevent. We fixed the race condition, and once it was fixed, I wrote a test for it — not out of discipline, but because I never wanted to find out about that failure from an furious client again. That was the first test I ever wrote with intention.
What stuck with me wasn't the fix. It was the shape of the mistake. Nobody had skipped testing that path because it seemed unimportant — nobody had thought about it as a path at all. The obvious things to test were the happy cases: book a slot, see it confirmed. The failure lived in the case nobody pictured: two people wanting the same thing at the same time.
That's the question I actually ask now, whenever I open a file with no tests: not "what's easiest to verify," but "what's the equivalent of the double booking here?" Every system has one — the failure that isn't rare because it's unlikely, it's rare because nobody has tested it yet. It's rarely the function that looks complicated. It's the one where two things can happen at once, or where a number silently becomes wrong, or where "this can't happen" was never actually checked.
Coverage doesn't ask that question — it treats every untested line as equally worth covering. It isn't. The first test in an empty file should target the failure that would actually cost you something if it happened again: a client's trust, a user's booking, a system's credibility. Not the line that's fastest to check off.
Write that one first.
Related articles
Get new articles in your inbox
Writing about pragmatic architecture, maintainable systems, and real-world engineering trade-offs. Published when ready.