It’s an interesting question. Personally, and irrelevantly, I’m not at all convinced the “run tests in txn then rollback” pattern is very good. My applications want explicit control over the application of transactions (and the handling of problems thereby). Not only do too many sql databases have weird nested txn semantics, it’s also means my test sql code (probably) runs in a different execution context than production sql code. However, that was not your question! I suspect what I would do in this situation would be to write a fixture fn that builds a system for its fns to use that uses the txn (your spec) in the db component, instead of taking an already built system and rebinding one of its values. Another approach would be to e.g. implement IDeref in your db component and use deref to acquire the db spec at the call sites.

Oh interesting! I didn't realize deref was something that could be used here. Thank you! These are awesome ideas, and I look forward to burning the bridge in your first paragraph caveat when I potentially realize it myself as well 😄