How do you run a Spring Boot app at dev time against Testcontainers-managed services?

## The problem it solves Integration tests had a good story for infrastructure — start a container, point the context at it — but local development did not. Developers installed Postgres by hand, ran an ad-hoc `docker compose` stack, or shared a remote dev database. Each of those drifts from what CI actually tests, and each is a step in the onboarding document that goes stale. Spring Boot 3.1 closed the gap by making the *test* classpath a legitimate way to launch the application. ## The mechanism `SpringApplication.from(...)` takes a method reference to your production `main` method — typically `MyApplication::main`. It does not run it immediately; it returns an object you can augment. `.with(Class<?>... configurations)` adds extra configuration classes on top of whatever the production main would have built, and `.run(String... args)` finally launches. So the launcher is a few lines in `src/test/java`, conventionally named after the application class with a `Test` prefix. Because it lives in the test source set, it can see the same `@TestConfiguration` class your `@SpringBootTest` classes import, and it never ships in the production jar. The container beans behave exactly as they do in a test: they implement Testcontainers' `Startable`, so Boot's `spring-boot-testcontainers` integration starts them as the context comes up and stops them when the context closes. Connection details reach the app through the same mechanism the tests use — you are not duplicating wiring, you are reusing it. ## Running it Three entry points, all equivalent: **From the IDE** — run the test-scoped main class like any other main method. This is the common path, and it gives you the debugger and hot-restart behaviour you already use. **Gradle** — the Spring Boot plugin contributes a `bootTestRun` task, which is `bootRun`'s sibling running against the test runtime classpath. **Maven** — the Spring Boot plugin contributes a `spring-boot:test-run` goal with the same intent. All three require Docker to be available, because there is nothing fake about the dependencies: a real Postgres process is running in a real container. ## Interaction with devtools and restarts With `spring-boot-devtools` on the classpath, a code change triggers a restart of the application context. Restarting a context normally means stopping its beans — including the containers — and paying full startup cost again. Boot's Testcontainers integration is aware of the restart classloader and keeps containers alive across a devtools restart rather than cycling them, which is what makes the workflow usable. If your loop still feels slow, the sibling concern is container reuse, which keeps containers alive even across JVM exits. ## What it does not replace This is a development convenience, not a deployment story. The containers are throwaway: data written during a session is gone when the process stops unless you configure otherwise. If you need seeded data, do it the same way tests do — an init script, a migration tool run at startup, or a `CommandLineRunner` guarded by a profile. It also does not replace `docker compose` for the case where you want the stack running independently of the app process. Boot has a separate Docker Compose integration for that; the Testcontainers route is the right one when you want the app to own the lifecycle of its dependencies and the same definition to serve both tests and dev. ## Why interviewers ask It separates people who have adopted the annotation from people who understand the wiring. The instructive part of the answer is that the dev-time launcher and the integration test share *one* configuration class: if a candidate describes maintaining two definitions — one for tests and one for local running — that is the drift the feature exists to remove. ## Practical cautions Keep the launcher class out of the pattern your test task picks up (a class named `TestMyApplication` is not matched by the usual `*Tests`/`*Test` conventions, which is why the prefix form is the recommended name). Pin image tags so local runs and CI agree. And remember that the first run on a machine pulls images, so the initial startup is much slower than steady state.