3 ms·
I've had good experience with testcontainers (https://testcontainers.com/ https://testcontainers.com/) to do that sort of thing.
by fcmgr 2y ago
I've had good experience with testcontainers (https://testcontainers.com/ https://testcontainers.com/) to do that sort of thing.
- kkarimi 2y agoYes it’s a shame that this is not leading the discussion, works very well and surprisingly efficient in our experience compared to manually setting up docker containers or docker compose
- donjoe 2y agotestcontainers is great. I struggled a bit with testcontainers due to the nature of one container per test which just felt too slow for writing gray/blackbox tests. The startup time for postgres was > 10 seconds. After a bit of experimenting, I am now quite happy with my configuration which allows me to have a snappy, almost instant testing experience. My current setup: - generate a new psql testcontainer _or_ reuse an existing one by using a fixed name for the container - connect to the psql container with no database selected - create a new database using a random database name - connect to the randomly generated database - initialize the project's tables - run a test - drop the database - keep the testcontainer up and running and reuse with next test With this setup, most tests run sub-second;
- addled 2y agoIf your table setup process starts to get slow like ours, checkout psql TEMPLATE (https://www.postgresql.org/docs/current/manage-ag-templatedbs.html https://www.postgresql.org/docs/current/manage-ag-templatedb...). Do the setup once to a db with known name, then use it as the template when creating the db for each test.
- paulryanrogers 2y agoYou can run Pg against a RAM disk too, if the container isn't effectively already doing that. And tests can often use a DB transaction to rollback, unless the code under test already uses them.