3 ms·
I would just create a per-test-file database (and delete it the next time the test runs). The overhead is very small (compared to booting Postgres) and it work
by jrockway 6y ago
I would just create a per-test-file database (and delete it the next time the test runs). The overhead is very small (compared to booting Postgres) and it works exactly like production because it is exactly production.
In general, I am not comfortable using an "almost equivalent" database for tests. Every database engine has its quirks, and if you don't know what they are, your program that passes its tests only "almost" works in production, which is annoying.
- oauea 6y agoAnd if you need to run expensive migrations, use a template database. https://www.postgresql.org/docs/current/manage-ag-templatedbs.html https://www.postgresql.org/docs/current/manage-ag-templatedb...
- majodev 6y agoWhile PostgreSQL templates allow to scaffold new databases (one per test-spec) quite fast, it's even faster to have a warmed up pool of databases ready: https://github.com/allaboutapps/integresql#background https://github.com/allaboutapps/integresql#background Disclaimer: author.
- oauea 6y agoOh that looks great, and very close to what I had in mind for the next upgrade of our in-house testing framework. Definitely going to give that a try soon. Thanks for posting it!