This is why you should:
- Write functional tests, not unit tests
- Not use compilers or other systems that do a lot of black magic (like changing the type signature of your functions (!))
- Write functional tests, not unit tests
- Not use compilers or other systems that do a lot of black magic (like changing the type signature of your functions (!))
My general rule is to never mock or remove anything that has no side effects from the execution path of a test, even if it's some utility function that's already tested in isolation in its own test suite - trying to isolate every little bit of behaviour to be tested separately is just a bunch of extra work for questionable benefit.
I still call these tests "unit tests", and I think a lot of people do also. But there are the dogmatic people to whom only a test covering a single function with all dependencies mocked out is a true unit test.
But I concede that a thing that coerces your functions into async without adapting the corresponding calls is hilariously broken.
But testing each class in the project with a Mockito-encrusted setup featuring cardboard bananas/gorillas/jungles—best practice in Java-land—seems tedious, and tedium is the enemy of a good testing strategy because programmers won't follow it. They'll bodge in a solution, get their teammates to lgtm it, and roll it out under the slightest bit of deadline pressure.