I’ve worked in code where isolated tests with mocks get in the way of refactoring.
This points to a design problem, which, when fixed, makes the “mocks problem” disappear.
Almost always this involves:
- inverting a dependency;
- depending on a smaller part of a collaborator;
- collapsing an obsolete layer.
What many people call “tightly-coupled to the implementation”, I interpret as “revealing unnecessarily complicated dependencies”.
Seeing it that way helps me fix the problem.
Listen to the tests; they’re telling you something.
When you don’t listen to the tests, you propagate decision problems throughout the system, and when you have comprehensive tests, sadly, you make the problem hurt more.
Most people find it harder to tolerate a more painful problem.
They feel compelled to do something about it.
Unfortunately, too many programmers blame the tests rather than the production code design.
When we hold our nose while copying and pasting code, it hurts the system, whether we’re wildly duplication production code or test code.