Mocks shouldn't be the first resort; they're there as a way to allow you to test code that you can't improve right now. I wouldn't want to use them on new code, but as a stepping-stone for testing and improving a large existing codebase they have their place.
That’s not what they’re for! Mocks allow you to design the interface of a new object by implementing that object’s collaborators before you implement the object itself. This is a very high-fidelity source of information about what the interface should look like; anything else is just (educated?) guessing.
> That may not be what they're "for" (wtf does that even mean?)
It means that “[mocks are] a way to allow you to test code that you can't improve right now” and “[mocks are] a stepping-stone for testing and improving a large existing codebase” is a mischaracterisation of the role and benefits of mocks.
If using them like that is useful for you then that’s great, but it’s misleading to say that that’s why “they’re there”.
Steve Freeman & Nat Pryce’s book [0], for example, is an excellent illustration of what mocks are for.
A mock is overkill for that case; a stub or a dummy implementation (e.g. in-memory datastore) suffices when the interface with the collaborators is small and well-defined, as it should be when making a new design. The case where you need a full-on mock object is, IME, only when the collaborator is not decoupled enough from the primary object.
The difference between a stub and a mock is about the object under test, not the collaborators that are being replaced with doubles. We use a mock when we want to test the object’s interactions with its collaborators; we use a stub when we don’t care about the interactions, only about the values that result from them.
What does that decision have to do with whether the interface is small and well-defined?
