[jnaddef]

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.

[wccrawford]

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.

[pydry]

Yeah, he's talking to you for sure.

[jnaddef]

Yep, and he did a very bad job at it (and so do you) if the goal was to change my mind. Do you maybe have arguments?