🛑 Stop Testing Your Code and Ignoring Your Database (Catching N+1 in Pytest)

Your green CI pipeline might be lying to you. 🚨 It tells you the code works, but it’s quietly hiding the N+1 database disaster that will bring down your production environment next week. As Python & SQLAlchemy developers, we spend hours writing tests to assert our application’s final state, but we treat the database layer like a complete black box. We test what the application does, but completely ignore how it does it. The business cost of this abstraction is expensive. 💸 Every inefficient query and silent lazy-load that slips into the main branch directly inflates your cloud bill and degrades the user experience. I got tired of this, so I built and open-sourced pytest-capquery. 🛠️ 🎯 What it does pytest-capquery treats SQL queries as first-class citizens in your Pytest suite. By intercepting the SQLAlchemy engine at the driver level, it enforces a strict, chronological timeline of your execution footprint. Instead of just checking if a function returns True, you can rigorously