3 ms·
There's only one way to do integration tests with DBs right, use a real instance of the DB. If you need to speed up the setup/teardown process, so be it. If you
by kodablah 6y ago
There's only one way to do integration tests with DBs right, use a real instance of the DB. If you need to speed up the setup/teardown process, so be it. If you need to fashion your tests to avoid uniqueness constraints, so be it. But every other approach such as running in transactions and then rolling back, intercepting calls like this library does, mocking, etc will inevitably result in missing some quirk with your SQL. FWIW, at my job, I've written hundreds of tests that use a single local instance of CRDB harmlessly and there aren't any performance issues of note.
- DoctorOW 6y agoThat's essentially what this is. It looks like they just spin up cockroach in a docker container and intercept queries as they're sent for some of the analytics features.
- eikenberry 6y agoThis looks more like a caching solution to me, not a way to skip integration tests with your DB. I can't seem to find how you invalidate the saved interactions, but I assume it must either detect changes or you manually clear the cache. This seems like a reasonable solution to speed up integration tests when you need to run them frequently. Particularly useful when adopting legacy code that that only supports integration testing due to poor design.