One specific case that I encountered recently was implementing "integration" tests, where I needed to test some behavior that relies on the global state of a database. All other tests before were easily parallelized, and this meant our whole service could be fully tested within 10-30 seconds (dev machine vs. pipeline).

However, the new tests could not be run in parallel with the existing ones, as the changes in global state in the database caused flaky failures. I know there will be other tests like them in the future, so I want a robust way of writing these kinds of "global" tests without too much manual labor.

Spinning up a new postgres instance for each of these specific tests would be one solution.

I would like to instead go for running the tests inside of transactions, but that comes with its own sorts of issues.

Because you may want to spin up a new postgres database to test a specific scenario in an automated way. Testcontainers allows you to do that from code, for example you could write a pytest fixture to provide a fresh database for each test.

I don't know about Postgres but a MySQL container can take at least a few seconds to start up and report back as healthy on a Macbook Pro. You can just purge tables on the existing database in between tests, no need to start up a whole new database server each time.

You can also reuse containers with test containers.

Now the next question might be "Well why use test containers then if you are reusing containers".

Because you can express these dependencies and drive the config programmatically from your code and test harness.

If you need that, sure, but often this will be too expensive (heat my laptop too much).

Testcontainers integrates with docker-compose [1]. Now you can run your tests through a single build-tool task without having to run something else and your build. You can even run separate compose files for just the parts your test touches.

1. https://java.testcontainers.org/modules/docker_compose/