Testing Integrations: Break It in the Lab, Not in Production
An integration that only met the happy path in testing will meet the ugly path in production. Test the failures deliberately, before go-live.
Most integration testing checks that good data flows correctly, and stops there. Then production serves up a malformed record, a timeout, a duplicate, and the integration nobody tested for failure falls over in front of real users. Test the ugly path in the lab, or production will test it for you.
Test with bad data on purpose
Feed the integration malformed records, missing fields, wrong formats, and confirm it handles them gracefully, rejecting cleanly, logging usefully, not corrupting or silently dropping. The happy path is the easy 10%.
Simulate the failures you'll actually hit
Target system down, network timeout, duplicate delivery, partial batch, these happen in production. Simulate them in test and verify the integration recovers as designed, because 'we assumed that wouldn't happen' is not a recovery plan.
Test the volume you'll really see
An integration that's fine with ten records may choke on ten thousand. Test at realistic volume so you find the performance wall in the lab, not during month-end.
Real scenario: a client tested their integration only with clean sample data, and it sailed through. Production's first bad record, a missing mandatory field, caused it to fail in a way that halted the whole batch. We rebuilt the test approach around deliberate failures and real volume. Production stopped surprising them. Break it in the lab, on purpose, so it doesn't break in front of the business.