Testcontainers with @SpringBootTest — The Integration Pattern

Testcontainers runs the real database, message broker, or cache in a Docker container during integration tests so your code talks to the same engine in tests as in production. The H2 default in @DataJpaTest is fine for trivial CRUD but silently passes tests for PostgreSQL-specific features that fail in production.

The modern Spring Boot 3.1+ pattern

• Annotate a static container bean with @ServiceConnection in a @TestConfiguration class
• Spring Boot auto-configures spring.datasource.url, Kafka bootstrap servers, Redis host/port from the running container
• Import the configuration into every @SpringBootTest — the same context cache and the same container are reused across the suite

The pre-3.1 pattern

• @Container static PostgreSQLContainer postgres = new PostgreSQLContainer(...) plus @DynamicPropertySource to wire the URL into Spring properties
• Verbose but works for older Spring Boot versions

The two patterns that make it fast

• static final container fields — one container per JVM, not per test class
• withReuse(true) plus ~/.testcontainers.properties enabling reuse — container persists across mvn test runs locally

Common pitfalls

• Non-static @Container fields start a new container per test class — kills the context cache and slows the suite
• Forgetting @AutoConfigureTestDatabase(replace = NONE) when using @DataJpaTest with Testcontainers — Spring replaces the DataSource with H2
• Pinning to :latest image tags — reproducibility issues across machines

In an interview, the strong answer is: `@ServiceConnection` + `static final` containers + `withReuse(true)` + a shared `@TestConfiguration` is the production-fidelity integration test pattern that doesn't break Spring's context cache or balloon CI time.