I don’t really understand that argument, and I don’t really feel safer making a change to a microservice inside a large system, as opposed to making a change to a monolith — the consequences of a mistake are equal in both cases (although harder to observe/debug in a microservice architecture) — am I missing something?
From the Amazon book description:
Quite simply, test-driven development is meant to eliminate fear in application development. While some fear is healthy (often viewed as a conscience that tells programmers to "be careful!"), the author believes that byproducts of fear include tentative, grumpy, and uncommunicative programmers who are unable to absorb constructive criticism.
Also, making mistake in microservice is more easily isolated, fixed and redeployed.
Other than that, microservices are business entities, rather than just tech entities. They can be scoped, evaluated and managed on business level. After all, you can ask another team rewrite the specific microservice. You can't do that with monolyth.
And the problem wouldn't be just buried in tech details and opinions.