© Liashko/Shutterstock.com
Entwickler Magazin
Mit Docker leistungsfähige Java-Integrationstests realisieren

Ein mächtiges Werkzeug

Wir als Java-Entwickler kennen Container schon zur Genüge. Nichts anderes sind ja die als WAR- und EAR-Pakete geschnürten Anwendungen, die wir alltäglich in verschiedenste Applikationsserver deployen. Das Ziel, Applikationen von der Laufzeitumgebung zu entkoppeln wird jedoch durch die JEE-Standardisierung nur begrenzt erreicht. Dazu unterscheiden sich die einzelnen JEE-Server zu sehr voneinander, denn sie bieten viel Zusatzfunktionalität außerhalb des Standards. Hier kann Docker eine Lösung anbieten, wobei die Applikationsserver gleich mit in den Docker-Container gesteckt werden. Darüber hinaus hilft Docker bei der Erstellung von gekapselten Integrationstests. Diese beiden wichtigen Aspekte werden in diesem Artikel näher betrachtet.

Roland Huß


Video: Application Server sind tot

Um Integrationstests und das Bauen von Docker-Containern erfolgreich zu realisieren, wird Docker idealerweise direkt in den Build-Prozess integriert. Für Maven-basierte Builds werden verschiedene Maven-Plug-ins vorgestellt und verglichen. Ein einfaches Beispiel demonstriert die Verwendung eines Plug-ins und zeigt die jeweiligen Besonderheiten auf. Docker kann den Entwickleralltag in zwei Bereichen entscheidend bereichern: Da ist zum einen die teils ungeliebte Pflege und der Betrieb von Integrationstests, die oft einen erheblichen Aufwand bedeuten und für die es mithilfe Dockers ganz neue Ansätze gibt. Außerdem besteht mit Docker zusätzlich die Möglichkeit, produktionsnahe Deployment-Artefakte in Form von Applikations-Images zu bauen, die anstelle der JEE-Artefakte wie WAR- oder EAR-Dateien durch die Continous-Delivery-Pipeline geschoben werden und die letztendlich in der Produktionsumgebung landen. In den folgenden Abschnitten werden diese beiden Aspekte im Detail beleuchtet.

Integrationstests

Eine Disziplin, die notorisch Kopfschmerzen bereitet, ist die Erstellung und Wartung von Integrationstests. Eine typische Eigenschaft von komplexen Tests ist, dass Sie externe Abhängigkeiten besitzen. Dazu gehören Datenbanken und Web Services aber auch LDAP-, FTP-, Messaging- oder SSH-Server. Es gibt verschiedene Möglichkeiten, diese Abhängigkeiten zu berücksichtigen.

Zunächst wollen wir aber definieren, was gute Tests ausmacht. Unsere Kopfschmerzen kommen meist daher, da oft eine oder mehrere der folgenden, nicht funktionalen Eigenschaften fehlen:

Robust: Ein Test sollte robust sein. Das heißt er sollte entweder immer erfolgreich sein oder immer fehlschlagen, wenn sich an dem zu testendem Code oder an den Tests selbst nichts geändert hat. Es gibt nichts Schlimmeres als flaky Tests, die eigentlich meistens funktionieren, aber halt nicht immer. Das Fehlschlagen dieser Tests lässt sich auch oft nicht reproduzieren. Die Ursache dafür ist eine oft temporäre Veränderung im Ausführungskontext der Tests. Das kann ein parallel laufender Test sein oder aber auch eine Änderung innerhalb der externen Abhängigkeiten.Autark: Tests sollten idealerweise autark lauffähig sein, sodass die Entwickler die volle und exklusive Kontrolle über alle Testparameter haben. Das schließt auch die Governance für externe Testsysteme ein. Andernfalls ist es oft die dann notwendige, zusätzliche Kommunikation, die einen Mehraufwand bedeutet.Isoliert: Wenn auf ...

Entwickler Magazin
Mit Docker leistungsfähige Java-Integrationstests realisieren

Ein mächtiges Werkzeug

Wir als Java-Entwickler kennen Container schon zur Genüge. Nichts anderes sind ja die als WAR- und EAR-Pakete geschnürten Anwendungen, die wir alltäglich in verschiedenste Applikationsserver deployen. Das Ziel, Applikationen von der Laufzeitumgebung zu entkoppeln wird jedoch durch die JEE-Standardisierung nur begrenzt erreicht. Dazu unterscheiden sich die einzelnen JEE-Server zu sehr voneinander, denn sie bieten viel Zusatzfunktionalität außerhalb des Standards. Hier kann Docker eine Lösung anbieten, wobei die Applikationsserver gleich mit in den Docker-Container gesteckt werden. Darüber hinaus hilft Docker bei der Erstellung von gekapselten Integrationstests. Diese beiden wichtigen Aspekte werden in diesem Artikel näher betrachtet.

Roland Huß


Video: Application Server sind tot

Um Integrationstests und das Bauen von Docker-Containern erfolgreich zu realisieren, wird Docker idealerweise direkt in den Build-Prozess integriert. Für Maven-basierte Builds werden verschiedene Maven-Plug-ins vorgestellt und verglichen. Ein einfaches Beispiel demonstriert die Verwendung eines Plug-ins und zeigt die jeweiligen Besonderheiten auf. Docker kann den Entwickleralltag in zwei Bereichen entscheidend bereichern: Da ist zum einen die teils ungeliebte Pflege und der Betrieb von Integrationstests, die oft einen erheblichen Aufwand bedeuten und für die es mithilfe Dockers ganz neue Ansätze gibt. Außerdem besteht mit Docker zusätzlich die Möglichkeit, produktionsnahe Deployment-Artefakte in Form von Applikations-Images zu bauen, die anstelle der JEE-Artefakte wie WAR- oder EAR-Dateien durch die Continous-Delivery-Pipeline geschoben werden und die letztendlich in der Produktionsumgebung landen. In den folgenden Abschnitten werden diese beiden Aspekte im Detail beleuchtet.

Integrationstests

Eine Disziplin, die notorisch Kopfschmerzen bereitet, ist die Erstellung und Wartung von Integrationstests. Eine typische Eigenschaft von komplexen Tests ist, dass Sie externe Abhängigkeiten besitzen. Dazu gehören Datenbanken und Web Services aber auch LDAP-, FTP-, Messaging- oder SSH-Server. Es gibt verschiedene Möglichkeiten, diese Abhängigkeiten zu berücksichtigen.

Zunächst wollen wir aber definieren, was gute Tests ausmacht. Unsere Kopfschmerzen kommen meist daher, da oft eine oder mehrere der folgenden, nicht funktionalen Eigenschaften fehlen:

Robust: Ein Test sollte robust sein. Das heißt er sollte entweder immer erfolgreich sein oder immer fehlschlagen, wenn sich an dem zu testendem Code oder an den Tests selbst nichts geändert hat. Es gibt nichts Schlimmeres als flaky Tests, die eigentlich meistens funktionieren, aber halt nicht immer. Das Fehlschlagen dieser Tests lässt sich auch oft nicht reproduzieren. Die Ursache dafür ist eine oft temporäre Veränderung im Ausführungskontext der Tests. Das kann ein parallel laufender Test sein oder aber auch eine Änderung innerhalb der externen Abhängigkeiten.Autark: Tests sollten idealerweise autark lauffähig sein, sodass die Entwickler die volle und exklusive Kontrolle über alle Testparameter haben. Das schließt auch die Governance für externe Testsysteme ein. Andernfalls ist es oft die dann notwendige, zusätzliche Kommunikation, die einen Mehraufwand bedeutet.Isoliert: Wenn auf ...

Neugierig geworden?


   
Loading...

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