Comment by lowbloodsugar
12 days ago
“Mocks only test the happy path.”
This is a problem with the test authors, not mocks.
“All the bugs are when talking to an actual database.”
Databases have rules that need to be fillowed, and a lot of those can be tested very quickly with mocks. The combined system can have bugs, so don’t only use mocks. Mocks and unit tests are not a substitute for all the other tests you need to do.
How this person can claim to be a CTO I have no idea.
He probably meant it takes more effort to create mocks for all the negative cases. In most cases you won't have the time or the bandwidth to do this.
Try mocking DB triggers, views, access rules etc in mocks and you will know why most teams don't bother mocking but use the real thing instead.
And about the comment about him being a CTO. Well he is a CTO and you?
Then he should have said that. Is not clear communication a requirement for CTO these days?
Everything you are describing is about actually testing the database. A database is a complex server and things like db triggers and store procedures should be tested isolation too. And then you have integration tests too.
My team just found a bug that wasn’t covered in a unit test. We found it in a long running API test. And so we added a unit test for the specific low level miss, and a quick integration test too.