A good rule of thumb is that if you need heavy mocking to get unit testing done, you should probably just integration and end-to-end test it.
Example 1: typical machine learning training microservice. You query a pile of data from a few DBs, join it and process it, train a model on it and evaluate it.
You could mock the DB queries to test it, but such a mocked unit test alone is dangerous (tests could pass when the relevant DB tables aren't updated correctly IRL) and doesn't add much of anything. Just integration and end-to-end test it.
A machine learning inference service OTOH is much more natural to unit test.
Example 2: you have an simple endpoint microservice with an internal caching structure (just for efficiency purposes).
The "unit" here is still the user facing endpoint, trying to write unit tests for the internal caching structure will tightly couple your internal API between the caching layer and the API facing service. This makes refactoring harder for the service will adding little upside for what's useful overall here.
You should unit test the cache THROUGH the unit tests of the endpoint service in this case if possible.
SOLID people tend to cry at "unit testing through something else", but this is actually what Kent Beck really meant by "unit" in the original design (a unit is at the software system level, not in the implementation level of a class being a unit).