3 ms·
Integration testing is especially important when talking to a database. People seem to like mocking the data, but that completely misses the subtleties of how d
by branko_d 9y ago
Integration testing is especially important when talking to a database. People seem to like mocking the data, but that completely misses the subtleties of how databases actually work, including aspects such as concurrency, transaction isolation levels, locking and such.
There should be a few well crafted tests that modify the database from several parallel threads, and afterwards verify that no invariants have been broken. This is pretty much the only opportunity to catch a race condition in a controlled environment.
- gipp 9y agoThis is the part I don't get when people preach the gospel of ultra-isolated test suites where nothing talks to an external system. The most nontrivial parts of your code, the most likely to break, are those that talk to external systems. Building a mock of that system sophisticated enough to sufficiently capture even a significant fraction of the "real" failure modes is just as, if not more error-prone and daunting a task. Totally isolated tests make it impossible to test the most failure-prone parts of your code in anything approaching a satisfactory manner. Maybe I'm just misunderstanding people's advice but it drives me crazy when I see that.
- MartinCron 9y agoA lot of the ultra-isolated test advocates seem to come from the kind of development world where you can exercise most of the value without needing to interact with external dependencies. With aggressive enough mocking, you can deceive yourself into thinking that any application is in that domain. I know I have done it, and the application worked PERFECTLY until I hooked it up to a real database.