Testing a lookup integration without spending your balance

Integrations against a metered API get tested less than they should, for an understandable reason: every test run costs something. The way out is noticing how little of the testing actually needs the network.

The six cases

A known good identifier returning a populated record is the obvious one, and it is the only case most integrations ever check.

The same identifier a second time is the case nobody writes and the one that explains the bill. If the second call reaches the network, the cache is not working, and that will not be discovered until the invoice looks wrong.

One digit changed should fail the checksum locally and never be sent. An unallocated code should come back as a documented not-found rather than as an exception. No key at all should produce a clean authentication failure, not a stack trace.

And junk — letters, spaces, an empty string, a pasted phone number — should be rejected before anything leaves the process.

Three layers, one of which costs money

Local validation is free and unlimited. Checksums, format classification, telling an MEID from an IMEI, rejecting nonsense — all of it runs without a network and should be the bulk of your test suite.

Recorded responses cost one real call each, once. Capture a genuine answer for each case you care about, store it as a fixture, and replay it forever. This is where the response-shape assertions belong, and it is what keeps your suite honest without keeping it expensive.

A live check is worth exactly one call before a release: proof that the key works, the network path is open and the contract has not changed underneath you. Running it on every commit buys nothing that the fixtures do not already cover.

Two things worth asserting that people skip

That failures are not charged. Send a bad checksum and an unallocated code, then check the account balance before and after. The contract says neither costs a lookup; verifying it once means you can rely on it in your retry logic.

That your error branches are distinguishable. If every failure path in your code logs "lookup failed", the test that proves you handle 402 differently from 422 cannot exist — and neither can the debugging session that needs the distinction at two in the morning.