There is also the impact of Agile.

Microservice theory assumes that services will be generalized and reusable. But in an Agile approach, one only builds the minimum of what needs — one rarely builds a general purpose anything. And so the result is that when a new user-facing feature is needed, one almost always has to change many services to implement the feature. That’s because services only have the minimum API needed to implement the current feature set.

This reality also impacts another theory that I often hear: that if one does thorough API level testing, then one does not need to do integration testing. But yes, one does, if one has changed several services. API tests are important, but they don’t specify temporal behavior (e.g., what happens if the timing — or even the sequence — of events varies), and don’t specify semantics: API contracts only specify fields and data types. Semantics are human level understanding of what the fields are for, and that can be interpreted one way by one service’s team and another way by another team.