In most systems, the outcome you engineer against is a red test suite. In a booking system it is the green one: a full-flow test that passes has just reserved something in a real inventory, under a real account, with a real cancellation policy attached.
The standard answers do not quite fit. Mock the supplier and you are testing your mock — the thing that actually breaks in this business is the conversation with the other side, not your own function calls. Point at a supplier sandbox and you are testing the sandbox, which has its own bugs, its own inventory, and its own idea of what a price looks like. At some point the flow has to run for real, and "for real" means a booking exists afterwards.
The full flow, through the front door
The full-flow tests run through the public HTTP API, as a staging test user: login → search → search-by-id → prebook → book → cancel. The same door a partner uses, the same contract, the same order of calls — not a harness wired into the internals. If the flow only works when you skip the front door, it does not work.
The last step is not cleanup bolted onto a test. Cancel is part of the flow being tested, because it is part of the product: a partner that can book through you but not cancel through you has a much worse problem than a failed test run.
The selection rule is the safety mechanism
Here is the part I find genuinely elegant, and it is one sentence: the test always selects the cheapest offer with free cancellation.
That rule is not a preference, it is the entire safety model. A successful booking can be unwound at zero cost — book, verify, cancel, and the ledger reads zero. There is no sandbox flag, no "test mode" the supplier has to honour, no cleanup job sweeping up forgotten reservations. The safety lives in what the test chooses to buy.
I like it because it is a guardrail in the tool rather than in the human — the same principle as every write protocol on this site. Nobody has to remember to pick a refundable rate at 11pm; the selector cannot pick anything else.
It has a cost, and the honest version of this essay names it: the rule means the flow only ever exercises the cheapest, freely-cancellable corner of the inventory. Non-refundable rates, the expensive end, the odd cancellation policies — the full-flow test never touches them by construction. That coverage gap is real, and it is the price of running the test at all.
Certification is a folder, not a checkmark
Integrating a new supplier ends with certification, and certification is where the philosophy shows. It runs a per-provider testcase catalog through the entire flow — search → price confirm → PNR/booking → retrieve → cancel — and for every testcase, the raw request and response plus the exact upstream call get crawled into a named folder.
That folder — the evidence pack — is the deliverable. Not the green run that produced it. Partners review the pack, because the pack is the only artifact that can answer their actual question. A green checkmark asserts "my code returned what my assertions expected", which is a claim about my code. The partner's question is "did you call our API correctly, in these scenarios, and what did it say back?" — and the only thing that answers it is the bytes.
Every failure is a curl
The provider logs are kept replayable: a failed case can be re-fired as the exact curl that was sent. This matters because integration debugging is really one question asked over and over — did we send the wrong thing, or did they answer wrong? A log line summarising the failure cannot settle that question. The exact request, re-fired in isolation, settles it in one step, and it turns "works on retry, no idea why" from a shrug into a reproducible case.
The numbers I do not have
I have not counted how many full-flow bookings the tests have made, and nobody has computed what the cancellations would have cost without the cheapest-free-cancellation rule — by construction that number should be zero, but "should be zero by construction" is a design claim, not a measurement, and I am labelling it as such.
The artifact is the point
The theme underneath all of it: in integration testing, the artifact is the evidence pack. A green suite without artifacts is an unverified claim — you are asking the reader to trust that the right calls happened, in the right order, with the right payloads, because a bit flipped to true. With the pack, nobody has to trust anything: the conversation is on disk, named, replayable, and reviewable by the one party who cares most and trusts you least.
Green is the summary. The folder is the proof.