>The author seems to believe people either mock everything or don't mock anything.
The author is saying that people frequently mock things that it would be more economic to just run because you've got the real thing right there. Building a model for it is an expensive waste that probably won't even match reality anyway and will demand constant maintenance to sync up with reality.
If you're overtly concerned with the speed of your test suite or how fast individual tests run then you're probably the kind of person he's talking about. Overmocking tends to creep in with a speed fetish.
When I am developing a feature, I want to know very fast whether or not my code's logic is correct. It is not rare during the development cycle to run the same test dozens of times because I made a silly mistake (or a few), and obviously if the test takes 30 minutes to complete it completely wastes my day of work.
Having a set of very fast running tests is absolutely necessary in my opinion.
Once I have validated that the piece of code I wrote is doing what I intended, then I want to run other tests that do not use mocks/fakes, e2e tests that can possibly take a whole day to complete and will allow me to see if the whole system still works fine with my new feature plugged in. But this comes AFTER fast unit tests, and definitely cannot REPLACE those.
This sounds exactly right to me. You write mocks for the things that could take too much time to run frequently with the real code. (And I'm assuming you'd also write it for things that you don't want to make actual changes somewhere, such as a third-party API that you don't control.)
But if it could be run locally, quickly, you wouldn't bother mocking it.
If that's all correct, I think you and I would do the same things. All the people screaming "no mocks!" and "mock everything!" are scary, IMO.
Mocks mean your code is too tightly coupled. You should be able to unit test your code by creating only fake data.
Things like dependency injection increase coupling to the point where you have to mock. Avoid dependency injection and other complexity within complexity features.
The author is saying that people frequently mock things that it would be more economic to just run because you've got the real thing right there. Building a model for it is an expensive waste that probably won't even match reality anyway and will demand constant maintenance to sync up with reality.
If you're overtly concerned with the speed of your test suite or how fast individual tests run then you're probably the kind of person he's talking about. Overmocking tends to creep in with a speed fetish.