Good article. Virtualisation surely brings great outcomes.

To be honest, I think if it's an integration with a data store (e.g., a database) that you're trying to test, it's better off to do that using an in-memory tool like H2 as you mentioned. It's easier, and does not require a docker demon running on your build containers/machines for the Ci/CD process.

There is a crucial use case for Testcontainers that is often overlooked. Imagine if you're trying to test the integration between a certain cloud service (like S3, or SQS). Integration between your server application and the cloud provider would essentially require a dev account to write the code and test it. With Testocontainers, it's possible to spin up a local instance of localstack (or similar analogues), and through that it is possible for you to write integration code that assuredly run without issues when we deploy it into dev/test/sandbox account(s). Ultimately, Testcontainers serves a dual-purpose of purposing integration tests for validation (for QA) and verification of developments (for developers).

In my experience of using Testcontainers (2+ years), I find that this dual-purpose is often overlooked by a lot of people. Most of the newcomers either design end-to-end tests, which integration tests are a subset of, or they just do integration tests without using Testcontainers as a proper TDD tool. After JUnit, Testcontainers is the best TDD tool I've ever encountered. I use it for my personal projects as well. In fact, I'm so attached to it I spontaneously add the dependencies when I create a new project (even at office).