> I barely ever have unit tests flagging real issues
That sounds like you work alone and haven't worked for a long time on a code base with unit tests. Or the unit tests are bad.
That sounds like you work alone and haven't worked for a long time on a code base with unit tests. Or the unit tests are bad.
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.
Yes, exactly what I thought, that's what you would hear from somebody who has experience working on large code bases with many contributors.
Or he is actually not realizing unit tests bring to attention code that is impacted by the change... Or his tests just do for dynamically typed language whatever static tying does on compilation :)