The Test of Time: The System Design Gap Most Tests Miss

A client once asked me a question that none of my tests could have caught: “But how do I know where this stock is?”

The feature he was asking about worked. It had been tested, and every screen did what it was supposed to do. Yet his question exposed a gap in how I had thought about the system, and it’s a gap I now look for in every project I review.

How the feature was meant to work

When I was building the stock module in One Click POS, moving stock between branches seemed simple. A manager creates the stock entry. The receiving branch confirms it.

The confirmation step was deliberate. Goods moving between branches need transport, and transport takes time. You also don’t want stock appearing at a branch just because someone at head office typed it in. The person receiving the goods should check what actually arrived before the system updates.

At feature level, everything passed. Whenever you looked, the entry was sitting at the receiving branch, ready to be confirmed.

What the tests didn’t see

Then the owner asked where the stock was. Branch 1 had sent the goods, so they were no longer on its shelves. Branch 2 hadn’t received them yet, so they weren’t on its stock page either. For as long as the goods were on the road, they existed only as a pending entry, and nowhere a manager would naturally look.

Nothing was broken. Every individual step worked. What was missing was time: the gap between two correct states, where real goods sit in a real truck and a real owner wants to know about them.

The fix was a new page, Stock in Transit, showing every pending entry for every branch in one view. It was small to build and obvious in hindsight, but invisible until someone running the business asked.

Why time is the test most systems skip

Building software has become easy, and so has testing it. You can write a feature, run it and watch it behave correctly in a few minutes. But those few minutes are exactly the problem. Most tests check what a system does at a single moment, and businesses don’t run at a single moment. They run across hours, days and weeks.

This matters most in complex business processes: stages with time between them, multiple inputs and outputs, and steps that depend on someone responding. That last one forces a design decision many systems never make explicitly: what happens when nobody responds?

For low-stakes steps, waiting for a response can stall the whole process, so a rule like “no response after 24 hours means approved” keeps things moving. For critical steps, the waiting is the point, and an automatic default would be dangerous. Neither answer is wrong. Not deciding is.

What I’d tell someone starting out

If you’ve shipped systems for real clients, this probably sounds basic. But when you’re starting out, the focus is naturally on the happy path: the flow works, so you move on. Until you step back and look at the big picture, time stays invisible. It’s one of the first things I look for when I review a project.

One habit helps: walk through every process with the clock running. Who is waiting at each stage, and for how long? What does each person see while they wait? What happens if nobody acts? If you can answer those three questions, you’ve tested something no unit test will.

Have you had to deal with something similar? I’d like to hear about it.