9 ms·
Ugh, the "integration tests are the only way" argument again. Test mocks are generally useful for catching most bugs, not all bugs. You still need a reasonable
by brodouevencode 3y ago
Ugh, the "integration tests are the only way" argument again.
Test mocks are generally useful for catching most bugs, not all bugs. You still need a reasonable level of integration tests to do that, and depending on the system, that may or may not be economical depending on several factors. It's that last part that people really should note - this is fine in monolith where you may have one or two external dependencies, but in a microservices architecture this might not be the case. The cost or impact of testing against external systems might be undesirable.
FWIW I'm a huge advocate of air-gapping testing environments and when having the necessary resources I tend towards using local docker containers to represent externals.
- PaulHoule 3y agoLast month I was working on something that involved very complex SQL queries using recursive CTE https://www.postgresql.org/docs/current/queries-with.html https://www.postgresql.org/docs/current/queries-with.html We try to avoid tests that really hit the database because they are expensive to run (like 20 seconds for those SQL queries, more like 5 seconds for all the other unit tests) but in a case like that you are not so concerned that the system generates the right SQL but that the SQL really works against real data structures. 20 years ago I thought mocks were a terrible boondoggle, then frameworks like Mockito came around which make them easy to write. Still there is something to say about having a system where you can test with true unit tests without mocks.