That may not be what they're "for" (wtf does that even mean?) but they're a damn good use of mocks. You can't fix everything right now.

> 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.

[0] http://www.growing-object-oriented-software.com/

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.

I don’t understand what this means.

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?