How effective are unit tests in reality?
I am under the impression that at some point unit tests turn into tests that test the dependency between the object under test and another object. Sure, one can always abstract dependencies using interfaces, but what happens when even the interfaces should be changed? What if the unit under test no longer relies on those dependencies?
If our tests fail because of dependency issues, does it mean they are too coupled to our code? Also, do we have to change them every time when we change the dependencies? If it happens quite often, is this a sign that our design is wrong?
I tended to believe that unit tests are an effective way to test ensure robustness, but if they are too coupled to the dependencies that our objects have with other objects (be they expressed as interfaces), it simply leads to more time wasted in fixing those tests to pass the new design. Am I wrong?
The thing is, I am perfectly aware of the existence of mocking frameworks, and so on. This is not the problem. The problem is what happens when you change your method's implementation and it simply doesn't call the mock anymore, and you start seeing a bunch of red lights in your test stack, because your mocks aren't called the way the way they should? Unit or Integration test, something should be done here, right?
If I start writing different mock methods for every test condition I like, what happens if I decide to change the signature of the class I've mocked? All my tests go to the trash bin, right? Is this normal, can it be avoided? Is it a design problem?