I've been critical of mock objects for testing for quite a while now (Mock Objects Despoil Your Tests). A persistent argument some people put in favor of mock objects is that they enable isolation of testable components.
As if that's a good thing in and of itself!
The argument often suggests that only through rigorous isolation (or at least primarily through rigorous isolation) can you determine which component fails due to a change. To this I respond "So what?" because it's wrong.
The goal of testing as I practice it is to give me confidence that code behaves as I expect it to (positive enforcement) and that future changes will retain that behavior (negative feedback). I don't care very much for isolation as a design principle in and of itself because it's more important to me that I test real code in situations as realistic as possible and that I have good coverage. Setting up a framework for mock object injection of every component possible reminds me of mathematicians in a convention hotel when the fire alarm goes off. Everyone shuffled out of bed, looked at the map of exits, then went back to bed relieved that, to quite, "A solution exists."
Some people push back on this (not mathematicians, who need the joke explained). "But how do you debug tests when many of them might fail when one component fails?" The same way you debug anything: you look at things and think about them and understand the system. It helps if you work in small steps and run your tests every few seconds or couple of lines of code. (I do this.) You would have to do the same thing if you had only one test assertion for every unique thing which could go wrong, and in that case, even the heartiest mocker admits that you have to test your system as a whole, because you don't know if it works together until you prove that it all works together.
I'm not suggesting that you should throw everything in one big bag and test it all end to end, every piece of it, but in the same way, I think you're silly to break it into tiny pieces and test every one of them in isolation, especially when you have to end up writing or generating lots of fake code you never actually use to drive it.
(Similarly if you practice rigorous isolation because you're afraid your tests will be slow then don't write slow tests.)
I don't care about isolation in as much as I care about testing the real APIs I've produced.
