Hacker News Reader

It’s not coming across in your comment, but Testcontainers can work with unit tests to start a container, run the unit tests and shutdown. For example, to verify database operations against the actual database, the unit test can start an instance of Postgres run tests and then shut it down. If running tests in parallel, each test can start its own container and shutdown at the end.

View on HN

Wouldn't that just massively, _massively_ slow down your tests, if each test was spinning up its own Postgres container?

I ask because I really like this and would love to use it, but I'm concerned that that would add just an insane amount of overhead to the point where the convenience isn't worth the immense amount of extra time it would take.

A better approach is to spin up one container and a _template_ database before the tests. Apply migrations to that database. Then, each test creates its own database from the template, runs, and drops the database.

Tests can be run in parallel, and they are fast because the database is prepared just once, tests simply make a copy.

We're doing this in my company, I'm happy how it works.

You can use one container for all tests.

https://java.testcontainers.org/test_framework_integration/m...

Reply on news.ycombinator.com