Favor real dependencies for unit testing
The heart of the argument presented is that using mocks <i>in unit tests</i> is problematic because if an interface is changed, that will possibly break every test that involves mocking that interface and that&#x27;s friction to making changes. This is silly. If you use real implementations and change the interface, you have <i>the exact same problem</i> except that your configuration&#x2F;setup is also likely to have to change in subtle ways.<p>Let&#x27;s just assume the absurd notion that a choice of creating tech debt or changing a common interface is a real choice. If there was a serious change that could not be accounted for with easy test changes, I&#x27;m not the only one to see the tests commented out with a &quot;TODO: fix these&quot;. Developers tend to be pragmatic.<p>If you want to change code you will always measure the effect it will have on the code and tests are incidental, not the primary concern. Make it work. Make it right. Make it fast. I want to be able to trigger all code paths and exceptions (make it good). Using a real dependency, I would be left in the unfortunate situation of depending on knowledge of the internals of that dependency. It may not allow me to execute specific paths via pure configuration at all.<p>I don&#x27;t think using real dependencies is a good idea at all for <i>unit tests</i>. Integration tests are a different and I do fear that they are being confused.