Great article & visualizations of how systems have gotten more complex over time. Per his suggestion of "testing against a service stub / fake server" (instead

Great article & visualizations of how systems have gotten more complex over time. Per his suggestion of "testing against a service stub / fake server" (instead of method-level mocking), my suggestion for large internal orgs is double down on this and have your service owners to ship their own stubs: https://www.draconianoverlord.com/2013/04/13/services-should-come-with-stubs.html/ https://www.draconianoverlord.com/2013/04/13/services-should... I.e. if your `accounts-service` team has an API that is used by ~20 other internal teams, why should each of those teams either a) pollute their tests with low-level method-based mocks that are brittle coupling to impl details, or b) each write their own `AccountsServiceStub` when the `accounts-service` team could ship both `accounts-service-impl` and `accounts-service-stub` artifacts that implement that same API. But the stub artifacts is a) in-memory, and b) has additional methods to facilitate creating & asserting against the in-memory data, both of which should ideally create a pleasant out-of-the-box testing experience for their downstream consumers.