What this prompt does
This prompt asks the AI to stand up a Testcontainers testing infrastructure for a Spring Boot [spring_version] application so integration tests hit real services instead of mocks. For the services you need ([services]) it produces a base test class with @Testcontainers and shared container lifecycle, container definitions with health checks, dynamic property injection via @DynamicPropertySource, test-data seeding and cleanup, a custom container for [custom_container] with init scripts, parallel execution with container reuse, CI optimization through image caching, example integration tests for [test_scenarios], debugging guidance, and performance tips to keep the suite under [max_time] minutes — with Gradle or Maven and CI config.
The structure works because testing against real Postgres, Kafka, and Redis catches behavior mocks cannot, but container startup and CI caching are exactly what can make these suites the slowest part of the pipeline. Designing lifecycle, reuse, and caching up front keeps the realism without the slowness. The @DynamicPropertySource wiring is what ties it together, injecting each container's actual host and port into the Spring context so tests connect to the running container instead of a hardcoded address.
When to use it
- You want integration tests that exercise real databases, brokers, and search instead of mocks.
- Your current tests use in-memory substitutes that miss database- or broker-specific behavior.
- You need shared container lifecycle and reuse so each test class does not pay full startup cost.
- You require a custom container such as
[custom_container]with initialization scripts. - Your integration suite is slow and you want it tuned under
[max_time]minutes. - You want CI configured with image caching so containers do not pull fresh every run.
Example output
Expect a base test class managing container lifecycle, container definitions for each of [services] with health checks, @DynamicPropertySource wiring, a custom [custom_container] setup, parallel-execution and reuse configuration, example tests covering [test_scenarios], build-tool configuration, and a CI pipeline section with caching. It is a testing-infrastructure scaffold plus example tests, not a single test file.
Pro tips
- List
[services]accurately so each gets a container with appropriate health checks and dynamic property wiring. - Use shared container lifecycle and reuse rather than per-test containers; repeated startup is the main reason these suites get slow.
- Define
[custom_container]with its init scripts (for example, PostGIS plus seed SQL) so the container matches production capabilities. - Enable container reuse locally for fast iteration, but verify CI still starts clean to avoid state leaking between runs.
- Treat the
[max_time]target as a real budget and apply the caching tips, since slow suites get skipped in practice. - Iterate by asking for one end-to-end test from
[test_scenarios]to confirm the wiring before building the full suite.
