Leichtgewichtiges Testen von Java EE - JAXenter
Warum benötige ich Arquillian?

Leichtgewichtiges Testen von Java EE

Michael Schütz und Alphonse Bendt

Mit der Java-EE-6-Spezifikation steht ein durchgängig standardisierter Technologie-Stack für die Entwicklung zuverlässiger und skalierbarer Java-Enterprise-Anwendungen zur Verfügung. Im Gegensatz zu früheren Versionen werden konsequent leichtgewichtige Konzepte realisiert, die eine effiziente Entwicklung ermöglichen.

Leider existiert auf Ebene der Testframeworks bisher noch keine adäquate Unterstützung für die einfache Realisierung von aussagekräftigen Unit-/Integrationstests. Bisherige Ansätze wie Cargooder Cactus lösen nur Teilprobleme. Diese bieten zwar Werkzeuge zur Realisierung von aussagekräftigen Integrationstests, für umfassende Tests muss jedoch ein hoher Aufwand in die Integration der verschiedenen Werkzeuge investiert werden. Aus eigener Projekterfahrung wissen wir, wie schwierig die Entwicklung von Integrationstests für Java-EE-Anwendungen sein kann. Aus unserer Sicht ist die Entwicklung von Tests aufgrund folgender Punkte kompliziert:

  • Fehlende Unterstützung für Testentwickler
  • Hohe Zusatzaufwände durch wiederholtes Zusammenbauen der Anwendung
  • Ansteuern des Applikationservers aus dem Test heraus
Fehlende Unterstützung für Testentwickler

Für den Autor eines Tests stellt sich die Frage, wie er direkt aus dem Test heraus auf die Ressourcen zugreifen soll. Der Entwickler einer EJB kann durch Verwendung der entsprechenden Annotation alle benötigten Ressourcen komfortabel in die eigene EJB-Implementierung injizieren lassen. Für einen Test gilt das nicht. Der Testautor muss mühsam händisch auf die benötigten Ressourcen zugreifen. Dazu muss der programmatische Weg à la EJB 2.x verwendet werden. (z. B. new InitialContext().lookup(…)).

Ein modernes Testwerkzeug sollte dem Testautor API-Unterstützung für die Entwicklung von Java-EE-Integrationstests bieten. Idealerweise sollte diese eng an das EJB-API angelehnt sein, damit keine neuen APIs erlernt werden müssen.

Hohe Zusatzaufwände durch wiederholtes Zusammenbauen der Anwendung

At the heart of Java EE applications lies the art of assembly and packaging enterprise applications. (Debu Panda, Reza Rahman, Derek Lane – Autoren von EJB 3 in Action)

Für eine hohe Produktivität ist es notwendig, die Zeit zwischen einer Änderung an Produktiv- bzw. Testcode und dem Fehlschlag bzw. Erfolg eines Tests zu minimieren. Idealerweise sollte ein Entwickler durch die Tests auf jede Änderung ein schnelles Feedback erhalten. Langsam laufende Tests werden von den Entwicklern nicht regelmäßig ausgeführt, wodurch es zu Qualitätsproblemen kommen kann.

Neben der reinen Ausführungszeit der Tests spielt hier der Zeitbedarf für eine Neuübersetzung der Applikation die zentrale Rolle. Moderne Entwicklungsumgebungen unterstützen heutzutage die inkrementelle Übersetzung des Projekts. Dabei werden nach Änderungen am Quellcode nur die davon abhängenden Codeteile neu übersetzt. Dies ist so schnell, dass das neu kompilierte Projekt üblicherweise direkt nach Abspeichern einer Änderung zur Verfügung steht. Unit Tests können dadurch sehr schnell ausgeführt werden.

Im Gegensatz dazu bestehen nicht triviale Enterprise-Anwendungen typischerweise aus mehreren JAR-, WAR- und EAR-Archiven. Für die korrekte Konstruktion dieser Archive wird ein Werkzeug wie Apache Ant oder Apache Maven verwendet. Diese profitieren nicht von der inkrementellen Übersetzung der IDE. Abhängig von der Größe des Projekts und der Komplexität der einzelnen Build-Schritte kann ein Rebuild schnell zeitintensiv werden.

Damit ergeben sich die Anforderungen an ein modernes Testwerkzeug:

  • Integrationstests sollten von innerhalb der IDE ausführbar sein und
  • Änderungen an Test- und Produktivcode sollten keinen Rebuild mittels des Konstruktionswerkzeugs (Ant/Maven) erfordern.
In unserem Blogartikel haben wir bspw. beschrieben, wie man mit Maven, JSFUnit und Cargo Integrationstests auf Basis von JSFUnit schreibt. Die dort beschriebene Lösung funktioniert, bei einer Änderung müssen jedoch bis zu fünf (war, ear, it-war, it-ear, it-cargo) Maven-Projekte neu gebaut werden. Das ist entsprechend zeitintensiv.
Ansteuern des Applikationservers aus dem Test heraus

Ein vollständiges Werkzeug muss in der Lage sein, den Lebenszyklus des eingesetzten Applikationsservers zu verwalten. Abhängig vom Testszenario muss der Server gestartet werden, Testcode und zu testender Code deployt werden, und schließlich muss der Container wieder heruntergefahren werden. Damit die Tests einfach zwischen verschiedenen Servern portierbar sind, ist eine übergreifende Realisierung dieses Mechanismus erforderlich.

Geschrieben von
Michael Schütz und Alphonse Bendt
Kommentare
  1. JavaProgrammer2014-03-05 00:44:39

    Ist es möglich den zweiten Teil erneut zu verlinken? Leider ist der Link nicht mehr gültig.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.