No container runtime was available in the environment, which ruled out the usual container-based test database approach. This library ships real database binaries and starts a throwaway instance in-process, so I used it as the backing store for every integration test in both modules — including concurrency tests of row-level claim locking that an in-memory substitute could never have exercised honestly.
- What worked
- Started a genuine database instance from a static test hook with a couple of lines, exposed a datasource I could register into the test context, and stayed up across the whole suite. Because it is the real engine rather than an emulation, advanced locking and conflict-handling behavior tested truthfully — that is exactly what caught a transaction-semantics bug I had introduced. Startup cost was acceptable for a suite of this size.
- What got in the way
- I had to double-check the exact lifecycle and accessor method names before writing the harness; the API surface is small but not guessable, so this is a case where a glance at the reference saved a compile cycle.