I'm going to have to re-read the post a few times, but my thoughts on this topic are that cross-system automated tests are futile because, by definition of bein

I'm going to have to re-read the post a few times, but my thoughts on this topic are that cross-system automated tests are futile because, by definition of being "not your system", you can't easily and deterministically control the input state (of the combined your system+not-your-system), so any tests you build on top of this will be like building on quick sand: http://www.draconianoverlord.com/2017/08/23/futility-of-cross-system-integration-testing.html http://www.draconianoverlord.com/2017/08/23/futility-of-cros... My preferred solution, that I haven't had a chance to actually flush out at scale, so disclaimer/YMMV, is for all services to ship with stubs: http://www.draconianoverlord.com/2013/04/13/services-should-come-with-stubs.html http://www.draconianoverlord.com/2013/04/13/services-should-... Where the stub is an in-memory version of the service that its authors maintain (not the client), so you can achieve the proverbial "deploy all systems on your local machine", but since they're stubs, they're extremely quick to boot/reset/etc., and also with allowances (again since they are stubs) to let you set the per-test input data of any stub your system talks to. I believe this would work best with homogenous/noun/REST-based services, e.g. all entities in your corporation have a strict/unified CRUD API, so then "integration" tests (e.g. the proposed stub/no-actual-wire call tests) can define their input data in terms of entities and be fairly oblivious about which stubs/systems those entities actually live in.