[jrockway]

I think we call those "fakes", and reserve mocks for those tests that count the number of times a function was called, yielding "change detector tests".

Personally, I find it best to not be too concerned about the terminology, and make sure your test doubles get the data that the code under test needs to the place that needs it. The more real code you can involve in integration tests, the better; only look at replacing real code with test doubles if there is a performance or reliability downside. Databases have never hit that performance/reliability downside for me; network services do.

[dkarl]

> Personally, I find it best to not be too concerned about the terminology

I second this. My experience is that some people know this terminology if they're actively learning or teaching the techniques, but most of the people I've worked with who know the techniques and apply them successfully don't know the terminology and use the word "mock" universally, so it usually creates more confusion than clarity to try to distinguish the different kinds of test doubles by name.

[kaczordon]

No, fakes are specifically designed to emulate the underlying dependency somehow so that you can assert on it’s state later. Stubs don’t try to do that at all and are mostly for returning a default response.