pytest fixtures that actually scale: patterns from 2 years of Python CI pipelines
I spent two years watching the same test suite failures in CI. Not logic failures — the test logic was fine. Infrastructure failures. The fixture that created a database table but didn't clean it u...

Source: DEV Community
I spent two years watching the same test suite failures in CI. Not logic failures — the test logic was fine. Infrastructure failures. The fixture that created a database table but didn't clean it up. The S3 mock that shared state across test files and produced a passing suite locally and a flaky one in CI. The fixture that took 4 seconds to set up because it was creating a full schema, and ran 200 times across the test suite. The failures had the same root cause every time: fixtures optimized for "it works" rather than for isolation, speed, and reliability under CI's parallel execution model. Once I understood the patterns that caused the problems, I could see them appearing in every codebase I touched. These are the four patterns I use now. They don't require any new dependencies — just a clear model of how pytest's scope and teardown machinery works. The scope problem (and why function scope is your default) pytest fixtures have four scope levels: function, class, module, and session