Yes, very much "it depends". Also terminology arguments - I'm not describing a monorepo. I'm describing a service repo which might have more than one deployable asset, because that makes the most sense and provides the highest quality software, for the given scenario.
Comments
If my process view decision is a 12-factor app (cloud native) I will have a process formation and multiple process types.
If it was a single 12F app though, that might still be be a single repo with all those process types in it.
I am somewhat with others who I've heard say "micro" is probably a misleading term. "Service" or "Logic Responsibility/Boundary" is probably more appropriate?
If it's multiple deployment assets, testing each component is the better approach.
However, this is the scary thing for devs from the old world.
As with anything, it's what works best I suppose.