Aseptic vs Testcontainers
Dieser Vergleich ist anders als die übrigen im Bündel, und das gehört vorweggesagt: Testcontainers und Aseptic konkurrieren nicht. Sie tauchen zusammen auf, weil Leute, die Integrationstests bereits mit Testcontainers gelöst haben, dazu neigen anzunehmen, dass es auch ihre Arbeitsumgebung löst — und das tut es nicht. Es sind zwei verschiedene Momente des Tages.
In einem Satz
Testcontainers ist eine Bibliothek, die aus deinem Testcode Container startet: du forderst ein Postgres an, du bekommst ein echtes, und wenn der Test endet, ist es weg. Der Test steuert den Lebenszyklus.
Aseptic ist eine Desktop-Anwendung, die ein Szenario von Services startet und laufen lässt, während du arbeitest, und dabei jede Abhängigkeit auf einen lokalen Service, deine Cloud-Umgebung oder einen Mock auflöst. Du steuerst den Lebenszyklus.
Die Tabelle
| Testcontainers | Aseptic | |
|---|---|---|
| Wann du es benutzt | Beim Ausführen eines Tests | Während du Code schreibst |
| Wem der Lebenszyklus gehört | Dem Test: entsteht und geht mit ihm | Dir: du startest und es bleibt |
| Wo es deklariert wird | Im Testcode, über seine API | In einem Szenario, außerhalb der Repos |
| Führt DEINE Services aus | Nein — Abhängigkeiten, nicht deine Anwendung | Ja, das ist der Punkt |
| Wohin jeder Service zeigt | Du verdrahtest es im Test | Pro Abhängigkeit: lokal, Cloud oder Mock |
| Einen Endpunkt von Hand aufrufen | Nicht sein Anwendungsfall | Ja |
| Funktioniert in CI | Ja, dort glänzt es am meisten | Nein — es ist Desktop-Software |
| Debugger auf deinem Service | Der deines Tests | Der Prozess ist lokal: wie immer |
| Lizenz | Open Source | Kostenlos für private Nutzung, kostenpflichtig für kommerzielle |
Nimm Testcontainers, wenn…
- Du willst, dass deine Integrationstests gegen ein echtes Postgres, Kafka oder Redis laufen statt gegen ein Double. Genau das ist sein Problem, und es löst es besser als alles andere.
- Du brauchst, dass das in CI genauso funktioniert wie auf deiner Maschine, ohne dass vorher etwas installiert sein muss.
- Du volle Isolation zwischen Läufen willst: jeder Test mit sauberer Datenbank, ohne Reste vom vorigen.
Nimm Aseptic, wenn…
- Dich nicht ein roter Test blockiert, sondern dass das Ausprobieren des Ablaufs von Hand bedeutet, vier Services zu starten, und unklar ist, in welcher Reihenfolge und mit welchen Variablen.
- Du einen Endpunkt aufrufen, das Log des Service nebenan lesen und ihn neu starten willst, ohne den Ort zu verlassen.
- Du mischen musst: zwei Services lokal, einer gegen die Cloud-Umgebung und einer gemockt, weil das VPN heute unten ist.
- Du die Umgebung als Datei teilen willst, damit jemand Neues klont, importiert und startet.
Wo Aseptic zu kurz greift
Es ist kein Testwerkzeug und läuft nicht in CI. Wenn du versuchst, es für das zu benutzen, was Testcontainers tut, wird dir das Wesentliche fehlen: Isolation pro Lauf, Start und Stopp vom Test selbst gesteuert, und eine API aus dem Code. Nichts davon ist da, und nichts davon ist beabsichtigt.
Testcontainers ist außerdem quelloffen, mit Jahren an Laufleistung und Bibliotheken in jeder Sprache. Aseptic ist in öffentlicher Beta, ist Desktop-Software, und die kommerzielle Nutzung ist kostenpflichtig.
Was am Ende meistens passiert
Beide werden benutzt, und die Naht ist sauber, weil jedes in einem anderen Moment lebt: Aseptic, während du schreibst —Szenario oben, Ablauf von Hand ausprobiert, Debugger angehängt— und Testcontainers, wenn du die Suite ausführst, auf deiner Maschine und in CI.
Der häufigste Fehler ist, das eine die Arbeit des anderen machen zu lassen: das ganze System mit Testcontainers hochzufahren, um „Dinge von Hand auszuprobieren“, endet in einem Test, der eigentlich ein Starter ist, langsam und schwer zu pflegen; und von einer Arbeitsumgebung die Isolation eines Tests zu erwarten, führt zu Suiten, die je nachdem fehlschlagen, was der vorige Lauf getan hat.
Wenn du in Wirklichkeit vergleichst, wie die lokale Umgebung zu bauen ist, ist der Ausgangspunkt wie man eine Microservice-Umgebung lokal betreibt, und danach der Docker-Compose-Vergleich und die Alternativen-Seite.
Häufige Fragen
Ersetzt Aseptic Testcontainers?
Nein, und das sollte es auch nicht. Testcontainers lebt in deinen Tests: der Container entsteht, wenn der Test startet, und stirbt, wenn er endet. Aseptic ist der Ort, an dem du arbeitest, während du den Code schreibst, mit Services, die oben und stabil sind. Normal ist, beide zu benutzen, jedes in seinem Moment.
Wenn ich schon Testcontainers habe, was fehlt mir?
Ein Ort, um Dinge von Hand auszuprobieren. Testcontainers löst die Abhängigkeiten eines Tests, nicht den Ort, an dem du den Ablauf ausführst, wenn du einen Endpunkt aufrufen, ein Log lesen oder den Debugger anhängen willst. Genau diese Lücke deckt niemand ab, und sie ist der Grund, warum irgendwann eine vierzigschrittige LOCAL_SETUP.md auftaucht.
Kann Aseptic Abhängigkeiten für meine Tests starten?
Dafür ist es nicht da. Ein Integrationstest will eine Umgebung, die mit ihm entsteht und stirbt, isoliert und in CI reproduzierbar; das ist genau Testcontainers. Aseptic ist ein Desktop-Werkzeug und läuft nicht in CI.
Nutzen beide Docker?
Ja, und für Ähnliches: Infrastruktur-Container. Der Unterschied ist der Lebenszyklus. Bei Testcontainers steuert ihn der Test; bei Aseptic du: du startest sie am Anfang und sie bleiben da, während du arbeitest.
Und wenn mein Problem ist, dass der Service nebenan nicht läuft?
Das ist ein Problem der Arbeitsumgebung, kein Testproblem. In Aseptic entscheidest du pro Abhängigkeit, ob dieser Aufruf zum lokalen Service, zu deiner Cloud-Umgebung oder zu einem Mock geht, und es wird beim Start angewendet, ohne das aufrufende Repository anzufassen.