We test against real infrastructure, not mocks — because mocks pass exactly when production would not.
A mock is a guess about how a dependency behaves, frozen in time. Tests built on mocks pass reliably — including when the real dependency has changed underneath them, which is the one moment you needed the test to fail. So wherever it is feasible, we test against the real thing. Our integration tests run against a local instance of the actual runtime, with real local stand-ins for the database, key-value store, and object storage, hitting real HTTP endpoints. The code under test does not know it is not in production.The tiers stack from fast to thorough. Unit tests cover the pieces that should be provable in isolation — business rules, the rollback logic of a saga, the validation on a typed identifier. Integration tests exercise whole flows through a running server: a multi-step order, an address validation round-trip, a compensation that has to unwind correctly. At the top, end-to-end tests drive a real browser through the genuine experience, including a full card checkout with 3-D Secure authentication run against the payment provider sandbox — the flow most likely to break in subtle ways, verified the way a user would actually hit it.All of it runs before anything deploys, gated in the same pipeline that lints and migrates. The point is not a coverage number; it is confidence that the paths a customer takes — especially the ones that move money — have been walked end to end by a machine, against real services, on every change. A test that mocks the payment processor proves your mock works. A test that drives a real sandbox checkout proves your checkout works.
In practice: the checkout suite drives a real browser through card entry and 3-D Secure against the payment sandbox on every change — so a regression in the flow that takes a customer's money is caught by CI, not by the customer.