[Sammi]

> I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decade ago). That took something like 10 minutes.

For anyone that doesn't know: With sqlite you can serialize the db to a buffer and create a "new" db from that buffer with just `new Datebase()`. Just run the migrations once on test initialization, serialize that migrated db and reuse it instantly for each test for amazing test isolation.

[yurishimo]

Assuming you use sqlite in prod or are willing to take the L if some minor db difference breaks prod...

This method is actually super popular in the PHP world, but people get themselves into trouble if they tidy up all the footguns that stock sqlite leaves behind for you (strict types being a big one).

Also, when you get a certain size of database, certain operations can become hideously slow (and that can change depending on the engine as well) but if you're running a totally different database for your test suite, it's one more thing that is different.

I do recognize that these are niche problems for healthy companies that can afford to solve them, so ymmv.

[torginus]

We've had this exact same issue (clean db for every test) - the way we solved it was with ZFS snapshots - just snapshot a directory of our data (databases, static assets, etc) - and the OS will automatically create a copy-on-write replica that can be written to, and the modification can be just thrown away (or preserved).

Once you've created a zfs snapshot, everything else is basically instant and costs very little perf.