Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Enhancement]: Document why singleton containers are required under Spring's test context caching

Aperta Adatta ai principianti
  • Qualcosa non va?
#11,967 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
1/5
Tempo stimato
Meno di un'ora
Idoneità per principianti
85/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
docker, java, spring
Ambito
documentation, testing

Direzione di ricerca

Inizia con la sezione "Singleton containers" di Manual container lifecycle control e confrontala con la documentazione di @Testcontainers e @Container nella pagina di JUnit 5. Aggiungi una breve nota che spieghi perché i container sotto @SpringBootTest devono sopravvivere alla cache del contesto di Spring e perché il pattern del static initializer si affida a Ryuk all'uscita della JVM; la documentazione è completa quando lo scenario di errore class-to-class e la motivazione sono chiari.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

type/enhancement
Module

Core

Proposal
The gap

The "Singleton containers" section in Manual container lifecycle control shows the static-initialiser pattern, and the JUnit 5 page documents @Testcontainers / @Container. Neither explains the failure that makes the singleton pattern necessary under @SpringBootTest, and the symptom is misleading enough that it costs people real time.

The failure

Spring caches the application context across test classes. @Testcontainers ties container lifecycle to the test class. Those two facts conflict:

  1. Test class A runs. The container starts. Spring builds a context pointing at the container's mapped port.
  2. Class A finishes. @Testcontainers stops the container.
  3. Class B runs. Spring reuses the cached context, still pointing at the container that was just shut down.
  4. Every test in class B fails with connection errors.

The misleading part is that class A passes and class B fails, and the error mentions nothing about containers. It reads like test pollution or an ordering problem, so that is where people go looking first.

Current documentation

Manual container lifecycle control says only: "Sometimes it might be useful to define a container that is only started once for several test classes." The JUnit 5 page does not mention Spring at all. So the pattern is documented, but the reason for it is not.

Proposal

Add a short note to the Singleton containers section: under @SpringBootTest, container lifecycle has to outlive Spring's context cache. That is why the containers are started in a static initialiser and deliberately never stopped — Ryuk reaps them at JVM exit, so nothing leaks.

I hit this building a Spring Boot project with Postgres and RabbitMQ containers and lost a while to it. Happy to open a PR if you would take it.

Lingua principale
Java
Stelle
8.7k
Fork
1.9k
Merge medio
17h 38m
PR unite (30g)
3

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di testcontainers/testcontainers-java

Tutte le issue di testcontainers/testcontainers-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.