[domano]

Dont take this the wrong way, but this is the answer i would get from enterprise devs usually when pointing this out.

Then i would realize that their definition of a real issue was completely removed from any business or user impact, but geared more towards their understanding of the process detail in question.

I would argue that there certainly are some good places for unit tests, like if you have some domain-driven design going and can have well defined unit-tests for your business logic, but this usually is the smallest part of the codebase.

Mocking things that talk to databases etc. usually gives a false sense of security while that thing could break for a whole number of reasons in the real world. So just dropping the mock here and testing the whole stack of the application can really do wonders here in my experience.

[toenail]

> this is the answer i would get from enterprise devs usually when pointing this out

Yes, exactly what I thought, that's what you would hear from somebody who has experience working on large code bases with many contributors.

[domano]

Ironically my experience has been that these responses came from people working in enterprise silos with few collaborators. Your mileage may vary.

[bebop]

Not disagreeing with your points. One thing mocks can be good at is to simulate errors that would be difficult to reproduce in an actual stack. For example, maybe you want to try and handle transient network issues or db connection failures, a mock could throw the correct exception easily, making your full stack do this would be challenging.