Slow test suites often measure database overhead, not actual code logic

A common reason test suites run slowly is that every test connects to a real PostgreSQL instance and runs migrations, even when the test itself never truly needs database interaction. The real cost is not total runtime but the delay between writing code and getting feedback, which breaks developer focus. The recommended fix is to apply the database schema once per session and wrap each test in a transaction that rolls back automatically, eliminating repeated setup overhead. Developers should distinguish tests that genuinely require database behavior — such as queries, constraints, or transaction boundaries — from those that merely use the database as a convenient way to build objects. Keeping a small, clearly marked set of true database integration tests while converting the rest to use plain objects can significantly reduce per-test setup cost.