I used to use mocks an awful lot more than I do nowadays. I learned to do that style of testing from the book Growing Object Oriented Software, Guided by Tests

I used to use mocks an awful lot more than I do nowadays. I learned to do that style of testing from the book Growing Object Oriented Software, Guided by Tests (the "GOOS" book, which is still well worth a read, even if you don't subscribe to that style of test driven development). I'm still of the view that mocks are extremely useful if a) you're working in a highly object oriented style (where systems are composed of objects that communicate with their collaborators by method call) and b) you're unit testing relatively small units of code at a time. Mocks are very useful if it's important to you that object X must call object Y, do a computation and then call object Z with the result. There are two key insights that helped me to eliminate the need for so many mocks: a) modern languages that support functional programming allow you to separate the concerns of computation and interaction with collaborators, and it's an awful lot easier to test drive a pure function that it is to test drive a graph of collaborating objects; b) modern hardware is sufficiently fast that it's much more feasible to spin up a whole service (or many services) in order to run tests on them, and you don't need to write fine grained unit tests merely in order to make the tests run quickly enough.