What I love about monolith is coherence and forcing you to do things well from the beginning. Microservice mesh tend to become horrible to maintain after a few years when no one really measure which components will be impacted by a single change. On the opposite, change one small 50 line function and your IDE will happily show you all the calls to that specific function.
So the consensus is to do things well from the start. IMHO both have their merits but strongly depend on the usecase. There is no one size fits all. A lot of thought has to go into both options to make them really effective. Otherwise it's just garbage in garbage out.
Depends how you do it. Having a sane communication model/interface between the services allows you to test it in two ways:
1) You test the internal structure with unit tests
2) You test changes to the API contract with E2E tests
Both are fairly straightforward once you set it up properly.
Same goes for the monolith, assuming you do your work on following somethink like the SOLID principle, it is easy to test piece by piece. The only thing here is that the interface contracts are internal to the codebase vs external to other codebases. (You might argue the last point actually forces you to write a more coherent API contract in both situations)
