Testcontainers — Running Real Databases in Tests
Fast recall
Quick revision
Core answer
Whether the candidate knows how to use Testcontainers effectively for realistic integration tests.
Starting a new container per test class instead of sharing across the suite.
Explain container reuse, @DynamicPropertySource, and Testcontainers' Docker Compose support for multi-service testing.
Interview-ready guide
Interview answer
Testcontainers runs real infrastructure in Docker — PostgreSQL, Redis, Kafka — during tests. The biggest mistake is starting a new container per test class. A 3-second container startup multiplied by 20 test classes adds a minute of pure overhead.
The fix: shared containers. Define a static container in a base class, start it once for the entire suite, and reuse it. With withReuse(true) and testcontainers.reuse.enable=true, the container even survives between test runs during development.
Always pin image versions — postgres:15.4 not postgres:latest. Use @DynamicPropertySource for connection URLs because Testcontainers assigns random ports. And handle test isolation explicitly: @DataJpaTest rolls back transactions automatically, but Redis and Elasticsearch need manual cleanup between tests.
Pre-pull images in CI to avoid download time during test execution.
Testcontainers — Running Real Databases in Tests
Direct Answer
Testcontainers runs real databases in Docker during tests. Use @DynamicPropertySource for connection URLs, share containers via static fields, and enable reuse for development speed.
Common Mistakes & Pitfalls
Starting a new container per test class instead of sharing across the suite.
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.