Tests that talk to a real database
What a test suite that shares a remote database with the dev server buys, and what it costs.
BariCare has no local Postgres and no schema per test. The test command talks to the same remote database branch the dev server does.
That means tests that touch shared tables, the job dispatcher above all, have to park and restore rows around themselves instead of relying on isolation. It works, and it is also why a failing test can leave residue behind.
What it buys: the clinical invariants live in the schema as CHECK constraints and a trigger, and a mocked database cannot test those. What it costs: speed, sensitivity to the order tests run in, and shared state.
The longer a suite grows against a shared branch, the more expensive it becomes to move to a schema per test. That is the cost I would weigh earliest next time.