3 ms·
You will find someday that you'd rather have tests that are comprehensive rather than tests that are fast. Especially when a significant portion of your program
by stickfigure 2y ago
You will find someday that you'd rather have tests that are comprehensive rather than tests that are fast. Especially when a significant portion of your program logic is in sql statements.
- mrkeen 2y agoCode which is unit testable is integration testable. Not the other way around. I test my units more thoroughly than integrations allow. Make the db return success, failure, timeout, cancellation, etc. One of my colleagues was trying to prevent a race condition towards the end of last year. He wanted the first write to succeed, and the second to be rejected. I suggested "INSERT IF NOT EXISTS". We agreed that it was the best approach but then he didn't put it in because the codebase doesn't typically use raw SQL.