At a high level: yep, completely agreed. In my experience, not-cleaning the database has consistently lead to more realistic tests, near-trivial parallelism, a

At a high level: yep, completely agreed. In my experience, not-cleaning the database has consistently lead to more realistic tests, near-trivial parallelism, and fewer errors. The extreme few exceptions (e.g. testing db-wide behavior, like reports) are easy to put in a special folder... and people will quickly grow annoyed with how slow they are to run in comparison, and will avoid adding them. It's a nice self-preserving feedback loop. My only recommendation / near-requirement for doing this: randomize your test order (prevents cross-test dependencies from leaking in), and consider running them twice in CI. Once with a clean DB (ensures you can bootstrap your test environments - it's easy to lose this unless you have something checking it), and once without cleaning (helps ensure you don't have imprecise tests, and just rerunning is a trivial way to get a decently-strong assertion, without having to resort to truly persistent shared databases). Or just do a weekly test with a clean db or something - bootstrapping problems are usually easy to identify and fix, it's fine if they leak temporarily. --- If you don't want to do this, or want a magic performance hack for db-bound tests while improving things: throw your test database onto a ramdisk. It's particularly easy with a dockerized DB: just use the ramdisk as the DB's volume.