The Test Has to Cross the Boundary

A test can pass and still leave the important question unanswered.

That does not necessarily make it a bad test. It may be a perfectly good test of something narrower than the claim we are about to make.

The booking-platform work has repeatedly brought us back to that distinction. We need to know not only whether the code produces the expected answer, but whether it does so under the conditions the service will actually face.

One customer is not two customers

Run two booking attempts one after the other and it is easy to demonstrate that the second sees the first one's work.

That does not establish what happens when both attempt to acquire the same remaining capacity at once.

The relevant boundary is the database transaction: what each participant can see, what it can change, and what happens when their work conflicts. A substitute database or a sequential runner cannot provide the same evidence as independent contention against the real database.

The September development record includes that real PostgreSQL gate, alongside rollback and restart tests. The value is not simply another set of passing cases. It is that those cases ask questions the earlier direct tests could not answer.

Permission changes the test

There is another easy way to obtain a reassuring result: run everything with an identity that can do everything.

That can establish that the operation is possible. It does not show that the intended service identity can perform it, or that a different identity is prevented from doing so.

Our database checks therefore included both allowed and forbidden operations under restricted roles. Success and rejection were both expected results, depending on who was asking.

The same distinction shaped the service design. A customer request, payment-provider evidence and background recovery work do not have the same authority simply because they eventually affect the same booking.

A skipped test is not a passing test

One recorded stage passed its direct tests while deliberately skipping the database-only cases. A later gate ran against PostgreSQL and passed all 32 cases without skips.

Both records are useful if we keep their meaning intact. The earlier result proves the direct checks. The later one adds database evidence. Neither establishes that a browser has completed a real payment journey.

This is where summaries need care. “Tests passed” is shorter than describing the boundary, but it can make a limited result sound much larger than it is.

Keep the unanswered questions visible

The complete booking journey was still unproven in the evidence used for this article. That is not something to conceal beneath the database results.

It is the next set of questions: whether the deployed entry points behave correctly, whether payment evidence arrives and is handled as intended, and whether the customer sees the right outcome.

Building Blue Canoe follows what we put together. Operating Blue Canoe begins with what we can responsibly depend on.

The useful question after a green result is therefore quite plain: which boundary did this test cross, and which one is still waiting?