The bug my test was actively protecting

I integrate with a lot of third-party APIs. Here is one that got me.

A vendor sends back a field called publicaly_available_post_id. That spelling is theirs. Missing "l", right there in the docs and on the wire.

My code read publicly_available_post_id. Correct English. A field they have never once sent.

Ordinarily you catch that in about four seconds. I did not catch it for months, because when I wrote the test I stubbed the correctly-spelled field too. So the test confirmed that my reader agreed with my stub. Both were written by me, on the same afternoon, holding the same wrong belief. Naturally they got along.

It got worse quietly, which is the part I keep thinking about. There was a fallback: if the ID is missing, store the temporary upload handle instead. So the first thing that ever published successfully stored a temporary handle in the permanent ID column. No error. The record looked completely normal. The actual damage showed up weeks later somewhere else entirely, when the metrics job asked for stats on an ID that had never existed.

The lesson I took: a stub you wrote is not evidence about the vendor, it is evidence about you. If the fixture and the code share an author and an assumption, the test can only catch typos, never a wrong belief. Somewhere in the suite there needs to be one real response captured off the wire, misspellings and all.