Re:Setting up PostgreSQL for running integration tests
by dagss on Friday April 19, 2024 @11:46AM
(#40088275)
The article is discussing the usecase where each test/set of assertions as a clean DB. I.e. hundreds of DBs per test run.
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.
Re:Setting up PostgreSQL for running integration tests
by williamdclt on Friday April 19, 2024 @10:59AM
(#40087675)
You're describing a pretty different testing strategy, where you only use one database and ensure isolation through transactions. It's a good strategy for your use-case, but it's not what the article talks about (they do mention this transactional approach and why it doesn't work for them)
Running the full suite of tests is about 5-10 mins on a relatively low-powered build server, whereas on my more robust development workstation it's about 3 mins. Getting a TestContainer running an empty DB for integration tests ends up being a very small portion of the time.
Most of the time any work being performed is done in a transaction and rolled back after the test is completed, though there are some instances where I'm testing code that requires multiple transactions with committed data needing to be available. The one ugly area here is that in some of these outlier test cases I need to add code to manually clear out that data.