© Enkel/Shutterstock.com
Integration-Tests mit Docker und Testcontainers

Containerschiff auf Testfahrt


Heutzutage ist Testing ein selbstverständliches Hilfsmittel für den Entwickler, um möglichst schnelles Feedback über den geschriebenen Code zu erhalten. Das gilt für Unit-Tests wie für Integration-Tests. Allerdings erfordern Letztere in der Regel Abhängigkeiten zu anderen Systemen. Eine Strategie, um diese externen Systeme und Abhängigkeiten verfügbar zu machen, ist es, eine gemeinsame Testinfrastruktur zu nutzen.

Solange wir einfache Unit-Tests schreiben, besitzen wir als Entwickler auch die nahezu vollständige Kontrolle über die Ausführung der Tests. Dieser Zustand ändert sich aber, sobald wir in der Testpyramide höher wandern und in den Bereich der Integration- und Functional-Tests gelangen [1]. Gerade wenn wir externe Abhängigkeiten, beispielsweise eine relationale Datenbank oder einen Message Broker, nicht nur mocken wollen – entweder weil der Nutzen den Aufwand nicht rechtfertigt oder es gerade um das Testen der Integration mit den echten externen Abhängigkeiten geht – benötigen wir eine Strategie, um diese externen Abhängigkeiten zur Verfügung zu stellen.

Besonders bei Microservices nehmen Integration-Tests einen großen Stellenwert ein. So hat Spotify kürzlich in einem Blogpost erklärt, beim Testen von Microservices keine klassische Testpyramide zu verwenden, sondern dass dort eine „Honigwabe“ zum Einsatz komme [2], bei der der Anteil von Integration-Tests größer sei als der der Unit-Tests. Das klingt erstmal nach einem Antipattern. Allerdings ergibt es Sinn, wenn man sich vor Augen führt, dass der Anteil des Integration-Codes bei einem Microservice oft sogar größer ist als die eigentliche Businesslogik.

Ein Weg, um diese externen Systeme und Abhängigkeiten zur Verfügung zu stellen, könnte es sein, eine gemeinsam genutzte Testdatenbank zu verwenden. In dem Moment, in dem ich mir Infrastruktur, die ich für meine Tests benötige, mit anderen Entwicklern oder sogar anderen Teams teile, wird aus meinem Integration-Test allerdings ein Integrated Test [1]. Integrated-Tests sind all jene Tests, die aufgrund der Korrektheit fremder Systeme erfolgreich sind oder fehlschlagen. Jeder, der schon einmal die schmerzliche Erfahrung machen musste, dass die eigenen Integration-Tests auf einmal scheitern, weil zuvor ein anderes Team seine Datenbankmigrationsskripte getestet hat, wird bestätigen, dass das kein idealer Zustand ist.

Eine Alternative besteht darin, die benötigten Fremdsysteme auf dem eigenen Entwicklerrechner zu installieren. Die Folge sind meist mehrer...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang