4 ms·
> 3. Does not allow running multiple test simultaneously. It does with almost every form of transaction isolation mode. Read uncommitted in Postgres still beh
by bpicolo 5y ago
> 3. Does not allow running multiple test simultaneously.
It does with almost every form of transaction isolation mode. Read uncommitted in Postgres still behaves as read committed, so in Postgres you're never missing the mark here.
> 1. That wouldn't work if code under test uses multiple transactions.
A lot of abstractions interpret nested transactions as save points for this reason.
It's not the only valid pattern, but it is a consistently behaving one that's straightforward to implement and gets you most of the UX you want from integration test design.
- vbezhenar 5y agoI still think that tests would be flaky without complete isolation in a different database instances. Transaction isolation is nice, but for serial isolation you would get errors when you can't commit that transaction and you'll need to repeat the test (which might cause further issues) and for lesser isolation levels you would get some phantom reads which might manifest as a rare test failures which is a terrible thing, because you can't reproduce it.
- bpicolo 5y agoThat's the best part - tests never commit data. Everything that happens is within the transaction, and only visible to that test. It doesn't let you test interactions of parallelized code doing independent/interacting database workloads, but most web/CRUD apps don't do that.