In Testcontainers, what does withReuse(true) do and what else must be configured for it?

## What reuse actually changes A normal container's life is bounded by the test run: started at the beginning, removed at the end by your code or by the Ryuk reaper. Reuse widens that boundary to span *runs*. The container stays up after the JVM exits, and the next run adopts it instead of starting a new one. ## The two-part switch Both halves are required, and this is the single most common source of "reuse does not work" confusion: 1. **In code**: `.withReuse(true)` on the container. 2. **On the machine**: `testcontainers.reuse.enable=true` in `~/.testcontainers.properties`. The split is intentional. Reuse changes what your test run leaves behind on the machine, so the library refuses to make that decision for you from code alone. A developer who wants faster local loops opts in; a machine that has not opted in — a shared CI runner, a colleague's laptop — runs the suite exactly as before, with no code change and no leaked containers. ## How a container is matched Testcontainers derives a hash from the container's configuration: the image name, environment variables, exposed ports, command, labels, copied files and so on. The hash is attached to the container as a label, and on the next start Testcontainers searches running containers for a match. Same configuration, same hash, container adopted. This is why editing a single environment variable causes a brand-new container to start: it is a different configuration, therefore a different hash, therefore no match. The previously reused container is not cleaned up for you — it keeps running until you remove it with `docker rm -f`. ## What reuse deliberately breaks The container is excluded from Ryuk's reaping and is not stopped at the end of the run; that is the whole point, and it is also the cost. Concretely: - **State persists across runs.** Rows, topics, keys and files written yesterday are present today. Any test that assumed a fresh database now depends on cleanup being done at the *start* of a run, not only at the end. - **Migrations become re-runnable.** Schema setup that assumed an empty database must tolerate an already-migrated one. - **Resources accumulate.** Configuration churn leaves a trail of orphaned containers on the machine. ## Why it is a laptop feature The documented use case is the local edit-run-debug loop, where saving several seconds on every iteration is worth a slightly dirty database. On CI the calculus inverts: runners are ephemeral or shared, a container left running is either wasted immediately or leaks onto a machine other jobs use, and a build that reuses state across jobs is no longer reproducible. The standard position is to leave the properties file untouched on CI, so the same code runs without reuse there. ## Reuse versus the singleton pattern They stack and solve different problems. The singleton pattern removes repeated startup *within* one JVM run; reuse removes it *between* runs. Reaching for reuse to fix a suite that starts a container per test class is treating the symptom — fix the sharing inside the run first. ## Interview framing Name both halves of the switch, name the configuration hash as the matching mechanism, and volunteer the state-leak trade-off with the reason it is per-machine opt-in. Candidates who only know the method call usually cannot explain why their reuse never engaged.