Turbo Boost für Arquillian Tests

Beschleunigen Sie Ihre Integrationstests um ein Vielfaches!

Integrationstests mit Arquillian

Arquillian ist ein von der JBoss Community entwickeltes Open Source Test-Framework für Java Enterprise Anwendungen und derzeit in Version 1.0.3 erhältlich. Mit Hilfe von Arquillian können Integrationstests für Java EE Anwendungen entwickelt werden, wobei uns die Ausführung auf einem Container (z.B. JBoss Application Server) abgenommen wird. Was Arquillian noch so alles kann ist auf deren Website näher beschrieben.

Mit diesem Artikel möchten wir Ihnen zeigen, wie wir mit ein paar Tricks die Ausführungszeit unserer Arquillian Tests auf ein Minimum reduzieren konnten. Wer sich erst mit der Funktionsweise von Arquillian vertraut machen möchte, dem sei der offizielle Guide empfohlen.

Automatisierte Tests müssen schnell sein!

Je schneller unsere automatisierten Tests laufen, desto früher erhalten wir Feedback ob in unserem Code noch alles in Ordnung ist. Bei steigender Projektgröße nimmt die Anzahl der Tests und somit die Ausführungsdauer dieser zu und man gelangt oft schnell an einen Punkt, an dem die Tests zu lange brauchen, um sie kontinuierlich auszuführen, um sicher zu stellen, dass der eben eingefügte Code die bestehende Funktionalität nicht beeinträchtigt.

Wer Continuous Integration praktiziert, der möchte nach jedem Commit einen automatischen Build anstoßen, der natürlich auch sämtliche Tests ausführen soll. Auch hier ist rasches Feedback wünschenswert, wer will schon eine Stunde oder gar länger warten, um zu erfahren, ob denn die Regressionstests nach seinem Commit noch durchlaufen? Von Continuous kann dann keine Rede mehr sein, und der Fokus auf funktionierende Tests über alle Ebenen rückt in den Hintergrund - die Tests werden nun deutlich seltener ausgeführt, das Feedback erreicht die Entwickler noch später, fehlgeschlagene Tests sind einzelnen Changesets nur noch schwer zuzuweisen usw. ...

Das Ziel soll also sein, dass alle Tests in nur wenigen Minuten durchlaufen, um unseren automatischen Build nicht unnötig zu bremsen, wie uns auch schon der 10-minutes Build aus Extreme Programming nahe legt. Während es hier verschiedene allgemeine Ansätze gibt, können auch werkzeugspezifische Optimierungsmaßnahmen angewandt werden - das folgende Beispiel richtet sich an Arquillian Tests.

10 Minuten für ca. 180 Integrationstests?

Als Veranschaulichungsbeispiel möchte ich ein kürzlich von uns entwickeltes Java EE 6 Projekt heranziehen. Schon recht früh bemerkten wir, dass die Integrationstests enorm viel Zeit in Anspruch nehmen - bei ca. 180 Tests dauerte die Ausführung bereits über zehn Minuten! Ausgehend davon, dass sich die Anzahl der Tests mit laufendem Projektfortschritt noch deutlich erhöhen wird, musste hier dringend eine Optimierung gefunden werden.

Die Ursache für die lange Ausführungszeit schnell gefunden, denn vor jedem Arquillian Test wird ein mit ShrinkWrap erstelltes Paket auf den Server ausgebracht, welches die entsprechende Testklasse inklusive aller Abhängigkeiten beinhaltet. Das Problem ist nun, das Arquillian es de facto nicht unterstützt, dieses Deployment auf Basis von Testklassen oder gar Testsuites durchzuführen. Bereits seit 2010 (!) existiert der entsprechende Feature Request (ARQ-197), wird aber erst für Version 2.0.0.CR1 versprochen, dessen Release Datum aber noch in den Sternen steht.

Der Turbo Boost: "Brute Force Arquillian"

Dass das Fehlen des oben genannten Features ein Problem darstellt, ist auch dem Projektleiter von Arquillian, Aslak Knutsen, durchaus bewusst. Deshalb hat er einen Workaround implementiert, mit dem der Mechanismus des einmaligen Deployments für mehrere Tests dennoch realisiert werden kann. Er nennt diese Lösung Brute Force Arquillian (wer sich den Source ansieht wird verstehen, warum) und stellt den Quellcode inklusive Anleitung frei zu Verfügung.

Mit Hilfe dieser Optimierung gelang es uns, die Ausführungszeit der Tests auf ca. 70 Sekunden zu reduzieren - das entspricht etwa einem Zehntel der ursprünglichen Zeit! Mit steigender Testanzahl steigt die Ausführungsdauer nun nur mehr sehr langsam an, da die Ausführung eines Arquillian Tests an sich nur zwischen 10 und 50 Millisekunden dauert (inklusive Leeren der Datenbank und anschließende Einspielung der benötigten Daten in die Datenbank).

02 Mai

Build Notification @ Objectbay

Von Daniel Haslinger

Bei Objectbay wird Continuous Integration gelebt! Wir zeigen Ihnen, wie wir mit gebrochenen Builds umgehen und wie Sie diese Methoden auch bei Ihnen umsetzen können.

22 Apr

Bollywood Scrum

Von Andreas Wintersteiger

Ihre Teams führen einen Backlog und planen Sprints im Abstand von zwei Wochen? Sie hängen schöne Charts auf, haben ein Taskboard und treffen sich jeden Tag um 9:30 Uhr und jedes Mitglied erzählt,...


Neueste Artikel

  • Und wo bleibt die Qualität? - Teil 2

    16.02. / Susanne Albinger

    Es ist leicht, über Qualitätsbewusstsein und kollektive Verantwortung des Teams zu reden. Aber oft ist es eine Summe von kleinen Dingen und Praktiken, die ein Team in die Lage versetzen, konstant hohe Qualität zu liefern.

  • Jenkins Pipeline Plugin

    14.02. / Gerald Hoheneder

    Der Sprint näherte sich dem Ende, die letzten Änderungen waren eingecheckt und alle Tests sind erfolgreich durchgelaufen. Es war also an der Zeit die neuen Features auf das Demo-System unseres Kunden zu deployen. Eigentlich kein Problem, schließlich sind das lediglich ein paar Klicks auf der Jenkins-Oberfläche und alles Weitere geschieht ganz von selbst und bedarf keiner weiteren ...

  • Und wo bleibt die Qualität?

    02.02. / Susanne Albinger

    Heutzutage ist Softwarequalität in aller Munde. Das Scrum Framework scheint ein Schritt in die richtige Richtung zu sein. Aber was muss wirklich passieren, um hohe Qualität zu liefern?

  • Dysfunktionen von Teams - 4

    23.01. / Alessandro Grimaldi

    Scheu vor Verantwortung ist die vierte Funktionsstörung unter der ein Scrum Team leiden kann. Im Rahmen der Teamarbeit, bezieht sich die Verantwortlichkeit auf die Bereitschaft ...