What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years. On the opposite change one small 50 lines microservice is a lot less risky!
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)
It's true you achieve higher isolation with microservices, but you also lose points in other areas. And you can get lost in your haystack of microservices just as easily as in your typical monolith ;)
How is a small microservice with one purpose different from a class / module with one purpose?
And if your microservice get to production with a syntax error do you really think the whole ecosystem is somehow more healthy? Not unless you wrote a ton of horrible defensive code with and retries and HTTP error/timeout catching code every time this service is called...
The real question is, do they have shared runtime state? If they don't, you can do the above, but if they do, moving to microservices won't make that go away, it might even make it harder to deal with.