© DrHitch/Shutterstock.com
Java EE Testing mit Arquillian

1 Testen von Java-EE-Anwendungen mit Arquillian


Eine häufige Beobachtung in der Praxis ist, dass Testen immer dann unter den Tisch fällt, wenn es zu kompliziert wird. Das trifft am ehesten für automatisierte Tests zu, die in der Verantwortung der Entwickler entstehen sollen. Wenn man sich dabei noch mit allerlei technischen Aspekten beschäftigen muss, trägt das nicht unbedingt zum Erfolg bei. Warum Arquillian zu einem unverzichtbaren Werkzeug in diesem Bereich geworden ist, soll hier betrachtet werden.

Im Container und doch frei

Das automatisierte Testen von Java-EE-Anwendungen gestaltet sich mitunter recht schwierig. Seit Einführung des POJO-Programmiermodells mit Java EE 5 kann man wenigstens in Unit Tests große Teile der Geschäftslogik automatisiert abprüfen. Darüber hinaus kommen aber noch unzählige Annotationen, Deployment-Deskriptoren, Dependency Injection und Convention over Configuration zum Einsatz. Deren Interpretation obliegt einem Container. Die Nachbildung einer solchen Ausführungsumgebung mag nur ansatzweise gelingen und ist nicht praktikabel.

Die Standardspezifikationen halten sich bei dem Thema vornehm zurück. Mit Java EE 6 wurde zumindest ein API zum testfreundlichen Ausführen eines EJB-Containers eingeführt. Aber was ist mit den anderen Containern bezüglich Servlets, CDI oder OSGi, ganz zu schweigen von deren Zusammenspiel in einem Integrationstest? Diese offensichtliche Lücke möchte Arquillian füllen [1]. Es handelt sich dabei um ein Testframework zur Ausführung von Java-EE-Code im Container. Für den Entwickler bedeutet der Einsatz eine deutliche Entlastung. Das Schreiben der eigentlichen Tests soll im Vordergrund stehen, nicht das Verwalten der Testinfrastruktur.

Funktionen

Arquillian deckt die folgenden Bereiche ab, die im weiteren Verlauf noch genauer beleuchtet werden:

  • Verwaltung des Lebenszyklus eines Containers
  • Anbindung an verschiedene Container
  • Zusammenstellung von Klassen und Ressourcen zu einem Deployment-Artefakt
  • Durchführung des Deployments
  • Erweiterung der Testklassen u. a. um Dependency Injection per @EJB, @Inject und @Resource

Der Testcode unterscheidet sich auf den ersten Blick nicht sonderlich von klassischen Unit Tests, da er auf JUnit oder alternativ TestNG basiert. Die Abhängigkeiten zu Arquillian innerhalb des Testcodes sind minimal gehalten. Auch bei der Ausführung der Tests muss der Entwickler nicht von seinen Gewohnheiten abrücken. Das ist wie bekannt direkt aus der IDE oder dem Build-Werkzeug möglich. All diese Punkte sorgen dafür, dass sich die Einführung i...

Neugierig geworden?

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