I have found that heavy use of mocking tools couples tests tightly to the design, resulting in great difficulty when I need to redactor. To me, the ideal is that I can change my design as I see fit without difficulty. My tests specify what my application does - how it behaves, not how it is structured. In my experience, this entails minimizing the number of points where tests touch production code, i.e. keeping the test suite DRY.

I do use test doubles, including mocks, where things become difficult or slow to test (generally application boundaries). But keep in mind that every line of mocking code costs more than an equivalent line of the alternative.

I would like to keep an open mind about this because I like the theory of decoupling.

But the only thing I use mocking/stubbing for is to mock out external services that make tests unreliable and slow (like HTTP requests).

Expectation based tests seem particularly easy to mis-use. Who cares how many times a method is called?

How would you test, say, payment processing, in any sane way, without mocking?

How do you test failure handling code when the failure can not be reproduced in a known way by the current code base?

I agree these tools are often overused, however they do have their roles.

Yeah I'm not referring to mocking external services, which is both smart and useful. I'm referring to the practice of endotesting whereby you mock your own objects and interfaces as a means to test interactions between them.