Tests Are for Your Future Self

Gergely Orosz wrote about coming back to a side project after months away. He made a change, and the tests he had written back then caught a regression before it shipped. That’s who tests are for. On the day you write one, you need it least: you know the code, you just ran it, and you’d probably catch the mistake yourself. The test earns its keep months later, when a teammate or the future you makes a change with none of that context.

The author forgets

Right now you know why the retry count is three. You know why the timestamp gets parsed as UTC, and which caller depends on the method returning nil instead of raising. That knowledge lives in your head, in a pull request description, and maybe in a Slack thread nobody will find again.

Give it six months. You’ll open the file and read it like someone else wrote it, because in every way that matters, someone else did. On a team it’s worse. The author may have moved to another team or left the company, and the reasons went with them. The code is still there, but the context around it has been leaking away a little every week.

A test keeps checking after you stop remembering

A comment records what you knew on the day you wrote it. It has no way to notice when the code drifts away from it. A test runs on every change and complains the moment the code stops doing what you understood it to do.

Take a common example. You fix a bug where a customer named “Smith, Jones & Co.” broke the CSV export because the comma in the name wasn’t quoted. You add a test with a comma in the name. A year later someone swaps the CSV code for a faster library that handles quoting differently. Nobody on the team remembers the original bug. The test does, and it fails before the change merges.

That test is the one piece of your understanding that outlasts your memory of it.

Maintenance is where the cost lives

Most of what a codebase costs gets paid after the first release. Every later change starts with the same question: what is this code supposed to do, and will my change break any of it?

Without tests, answering that means re-deriving the behavior by reading code, asking around, and clicking through the app. Or it means skipping that step and hoping. The first option makes every change slow. The second makes every change risky. Over the life of a system, those two costs add up to most of the maintenance bill.

With tests, the question gets answered by running the suite. That’s what lets a team keep shipping quickly years into a codebase instead of slowing to a crawl. The time you save by skipping tests this week is borrowed from whoever touches the code next, and they pay it back by working slower and breaking more.

Write the test while the context is cheap

The best time to write a test is when you understand the code best, which is right now. A test written six months later means reconstructing the context first, which is the exact work the test was supposed to save. “We’ll add tests later” usually means someone with less context adds them, or nobody does.

A few habits pay off for whoever reads the code next:

• Every bug fix ships with a test that reproduces the bug. It already happened once, which makes it the most likely thing to happen again.
• Every odd rule gets a test. If the code skips tax for one region or rounds a certain way on purpose, that decision belongs in a test, where a future change can’t quietly undo it.
• When you’re about to write a comment that says “don’t change this,” write a test instead. An assumption that lives only in a comment is implicit in the worst way, because nothing ever checks it.

“It’s just me” doesn’t last

Side projects are where people most often skip tests. It’s just me, I know the code, I’ll be careful. Gergely’s experience is the counterexample. A few months away from a codebase is enough to turn its author into a newcomer, and newcomers ship regressions.

The same goes for the prototype that becomes the product, and the one-off script that becomes a scheduled job. Code you write for yourself today has a way of becoming code someone else maintains.

Write the test for whoever opens this file next year. Odds are good it’s you.