[hack_edu]

I don't understand your point. If your third-party APIs are volatile and out of your control, causing a liability in maintaing tests... wouldn't that cause an even bigger liability in your application code? Such volatility is even more dangerous to your application. This is why we have integration tests.

This is classic case of why you need tests and integration policy. When your APIs change or break, the tests break and you are quickly made aware. You just saved yourself a huge embarrassment and likely have the competitive advantage to those we don't look forward like you should do. Need to make a release quick and need to update your handlers? Go for it. If you're on a deadline and secure with the release, go ahead and push it with a couple tests breaking with false-negatives then swing back for an hour and fix them.

You'll thank yourself when they release v2 of that API and sunset your methods.

[hartator]

I agree in parts. In real life, you can't always do integration tests against third parties for various reasons, the main one is that some websites/apps don't like to be taken as a sandbox to try out every CRUD operations we can have in mind. If you isolate too much, your code will be running against only itself and won't be again that useful. The way to assure software quality for our case is to carefully check on logs from data from real users, pretty regular actually. Not as sexy as TTD, but customers appreciate you take care about their real account or not another Foo Bar [e-mail] profile.