4 ms·
It sounds like your integration architecture is a mash-up. It is indeed quite difficult to handle external systems that are so tightly coupled to your own. For
by couchand 3y ago
It sounds like your integration architecture is a mash-up. It is indeed quite difficult to handle external systems that are so tightly coupled to your own.
For standard server-server integrations, where the coupling is limited to an (hopefully eventually) well-documented API surface, it's much more straightforward to replace an external service with an internal mock.
For CI purposes, we eventually develop a more-or-less complete internal version of every external service, quirks and all. It's fun to see their bugfixes show up in our git history in behavioral mocks.
We don't put much emphasis into automating integration testing. We've found that with all the vagarities of flaky external services, it's usually necessary to have a human in the loop somewhere for integration tests.
- crabbone 3y ago> more-or-less complete internal version of every external service Imagine what an integrator who works with public cloud would have to do? Now imagine that integration with three different public cloud is only a small fraction of what our software offers...
- couchand 3y agoOur clients integrate with all manner of public and private APIs and this is how we build every one of them. The flakier the provider, the more the gambit pays off. You don't have to build the whole API, just the parts you use. And you don't have to implement the real service at all. It amounts to just a bit more overhead the first time you use a new API, but that's dwarfed by the amount of time your team spends learning how the thing "really works" anyway.