31–40 of 50 posts
Why can't you just create a pool of databases and truncate all tables after each run ? That should be pretty fast
But yea, DELETEing is faster than creating a DB from template (depends on how much you have to delete, of course). However, templates allow parallelism by giving its test its own database. I ended up doing a mix of both: create a DB if there's not one available, or reuse one if available, always tearing down data.
Earlier quoted context omitted.
Testcontainers are anything but fast in my experience. With the image pre-pulled, the most basic mysql testcontainer takes about 5 seconds from calling RunContainer to it being ready to go.
I use TestContainers in my Java Spring Boot application coupled with Liquibase. I have it set up so that the PG instance is created once with Liquibase initializing it from vanilla PG to a fully created empty application database, then all the integration tests reuse the same by overriding the stop() method to an empty one. Running the full suite of tests is about 5-10 mins on a relatively low-powered build server, w…
There's one idea I'm not sure being described. Basically you create docker container from some postgres image. Then you run DDL scripts. Then you stop this container and commit it as a new image. And now you can create new container from this new image and use it for test. You can even parallelize tests by launching multiple containers. It should be fast enough thanks to docker overlay magic. And it should work with…
I would think the fundamental issue with this is similar to what the author described with template databases: > However, on its own, template databases are not fast enough for our use case. The time it takes to create a new database from a template database is still too high for running thousands of tests: And then in the timing shows that this took about 2 seconds. Launching another container is surely going to be…
There's one idea I'm not sure being described. Basically you create docker container from some postgres image. Then you run DDL scripts. Then you stop this container and commit it as a new image. And now you can create new container from this new image and use it for test. You can even parallelize tests by launching multiple containers. It should be fast enough thanks to docker overlay magic. And it should work with…
I would think the fundamental issue with this is similar to what the author described with template databases: > However, on its own, template databases are not fast enough for our use case. The time it takes to create a new database from a template database is still too high for running thousands of tests: And then in the timing shows that this took about 2 seconds. Launching another container is surely going to be…
-- Prevent new connections to template db
update pg_database
set datallowconn = false
where datname = 'my_template_db';
-- Close all current connections
select pg_terminate_backend(procpid)
from pg_stat_activity
where datname = 'my_template_db';There's one idea I'm not sure being described. Basically you create docker container from some postgres image. Then you run DDL scripts. Then you stop this container and commit it as a new image. And now you can create new container from this new image and use it for test. You can even parallelize tests by launching multiple containers. It should be fast enough thanks to docker overlay magic. And it should work with…
Your solution requires spinning up hundreds of docker images per test run..
We do the same thing as described with MS SQL; takes about 1 sec to get a fresh DB that way.
While MS SQL takes 30 seconds or something from Docker image.
Earlier quoted context omitted.
Testcontainers are anything but fast in my experience. With the image pre-pulled, the most basic mysql testcontainer takes about 5 seconds from calling RunContainer to it being ready to go.
I use TestContainers in my Java Spring Boot application coupled with Liquibase. I have it set up so that the PG instance is created once with Liquibase initializing it from vanilla PG to a fully created empty application database, then all the integration tests reuse the same by overriding the stop() method to an empty one. Running the full suite of tests is about 5-10 mins on a relatively low-powered build server, w…
Are you talking about a single DB reused for each test? That is of course no problem...
Our suite spends 3 to 10 minutes to run too. It provisions about a hundred databases (takes 1 sec each DB template clone.. the wall clock is running stuff in parallell)
Also, every time we change code and run a related test locally we make a new DB to run its test. If that took more than 1 second I would go crazy.
Each time the hash of our migrations change, we make a new template DB. That takes about 30 seconds to run all our migrations..
If the hash didn't change, clone the template of the given hash. This takes less than 1 second.
Some advantages not mentioned in article:
- When developing locally, a new DB clone is made to run my single test interactively. If this took much more than a second I would get rather annoyed.
- Yes a test suite can share a DB for full suite if all tests are written without hardcoding anything and provisiom new IDs always etc. But it is super useful to run a function QueryDump("select * from MyTable") in the test of the code I am working on and the full table dump only having what that single test worked on during debugging, speeds up debugging a lot vs querying for whatever random ID my test allocated.
Why can't you just create a pool of databases and truncate all tables after each run ? That should be pretty fast
DELETE is faster on a small amount of data. But yea, DELETEing is faster than creating a DB from template (depends on how much you have to delete, of course). However, templates allow parallelism by giving its test its own database. I ended up doing a mix of both: create a DB if there's not one available, or reuse one if available, always tearing down data.
It can run in parallel if you name schemas randomly, or by test name.
You only need one DB, no need to even re-connect, start DB cluster or whatever. It can all work with a single persistent connection.
And it's much less resource intensive.