644 tests, and why it matters

At the end of a long working day the counter stood at 644 passing tests. A nice number to look at. But the number itself is not the point. The point is what those tests do on a day when I am tired, in a hurry, or overlook something.

This is a solo project. There is no colleague reviewing my work, no team that raises the alarm when I make a mistake. And the system is going to trade with real money. Those two things together, working alone and money at stake, make a test suite not a luxury but a necessity.

What tests replace

In a normal team you have people around you who catch mistakes. Someone who says in a review "wait, this breaks that other thing". That layer is missing when you work alone. Tests are the replacement for it. They are the collective memory of every mistake ever made and fixed, recorded so they cannot creep back in.

Every time a bug was found and fixed, a test was added that covers exactly that situation. Not to inflate the number, but so that specific fault can never silently return. A bug you once had and repaired, you do not want to accidentally reintroduce a month later because you changed something else.

That is how a test suite grows on its own. Not by thinking up 644 tests in advance, but by turning every fault into a safety net. The number is a by-product of that habit, not the goal.

The test that describes the real fault

The best kind of test is one that captures a fault you actually had. When a bug surfaced this week where the system could hit the wrong bookkeeping record, the fault was not just fixed. A test was added that mimics exactly that scenario: precisely the situation that went wrong, with the expectation that it now goes right.

That is worth more than a hundred generic tests. Because if anyone ever accidentally reverts that fix, that one test immediately goes red. Today's fault cannot become the fault of six months from now.

The same held for a correction to the system's bookkeeping. The core of that fix was that it had to leave the positions alone, because they were already correct. The most important test was not whether the correction worked, but whether the positions were exactly the same afterwards. That test proves what the fix must not do. Sometimes that is more important than proving what it does.

Tests as permission to keep working

There is another reason this number does something for me. It gives me permission to keep working without being afraid.

When I change something and afterwards all the tests are green, I know I did not accidentally break something else. That sounds small, but it is the difference between daring to move forward carefully and being paralysed by doubt. Without that safety net every change would be a gamble. With that safety net every change becomes a controlled step.

Precisely when you work alone that is invaluable. Nobody else confirms it still works. The tests do, every time, in seconds.

What this taught me

A test suite is not proof that your code is perfect. Tests only catch what you thought to test, and there is always something you did not foresee. But for a system that is going to run with money, built by one person, it is the closest replacement for a team looking over your shoulder.

The number 644 does not say "this system is flawless". It says "644 times something was recorded that can no longer break silently". That is a very different kind of confidence, and a more honest one.

Do not build tests to hit a number. Build them so that every fault you once had can never be a surprise again.