>Explain then what is your alternative to unit and integration tests.
Tests against real components instead of mocks.
>If your tests either leave out invariants that are behind bugs and regressions or have invalid/insufficient inputs, the problem lies in how you created tests, not in the concept of a mock.
Nowadays external components can be very complex systems e.g dbs, messaging queues, 3rd APIs and so on
A lot of things can go wrong and you arent even aware of them in order to get mocks right.
Examples? fuckin emojis.
On mocked in memory database they work fine, but fail on real db due to encoding settings.
I'm not a fan of extensive mocking but you're conflating two rather different test cases. A test where you mock out the database connection is testing something in application code, which has nothing to do with database configuration. You should of course have tests towards the database too, but then you'd mock out parts of the application instead and not the database itself.
>A test where you mock out the database connection is testing something in application code, which has nothing to do with database configuration.
Wdym?
You're testing e.g simple crude operation, e.g create hn thread
With mocked db it passed, with real db it fails due to encoding issue.
The result is that tests are green, but app does not work.