Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#11,967 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

@zakaullah075 arbeitet bereits daran.

Seit 14.8.2026.

  • #11968 von @zakaullah075 — offen

Bewertung

Schwierigkeit
1/5
Geschätzter Aufwand
Unter einer Stunde
Anfängerfreundlichkeit
85/100
Issue-Typ
Dokumentation
Klarheit
Klar beschrieben
Aktivitätsstatus
Ruhig
Tech-Stack
docker, java, spring
Bereich
documentation, testing

Rechercherichtung

Beginne mit dem Abschnitt "Singleton containers" in Manual container lifecycle control und vergleiche ihn mit der Dokumentation zu @Testcontainers und @Container auf der JUnit 5-Seite. Füge eine kurze Notiz hinzu, die erklärt, warum Container unter @SpringBootTest den Spring context cache überleben müssen und warum das Muster mit dem static initializer beim JVM exit auf Ryuk angewiesen ist; die Dokumentation ist fertig, wenn das class-to-class failure scenario und die Begründung klar sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Java
Sterne
8.7k
Forks
1.9k
Ø Merge
1 T. 5 Std.
Gemergte PRs (30 T.)
1

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus testcontainers/testcontainers-java

Alle Issues in testcontainers/testcontainers-java

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.