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

  • Flux Application Architecture

    12.10. / Jimi Steidl

    In der Welt der Frontend Entwicklung existieren zahllose Frameworks in allen möglichen Sprachen, doch die meisten haben eines gemeinsam: Die Architektur. Seit vielen Jahren ist hier Model-View-Controller (MVC) Pattern der Platzhirsch, mit wenigen Model View ViewModel (MVVM) Vertretern. Anwendungen werden immer komplexer und man konnte beobachten, dass Implementierungen des MVC-Musters sehr ...

  • Summit 2017

    26.09. / Camilla Franek

    Dieses Mal blieb es bis zur letzten Sekunde ein Geheimnis was uns auf unserer diesjährigen Summit in Bratislava erwarten würde. Für 27 helle Köpfe ging es von 14. - 16. Oktober in die Hauptstadt der Slowakei - die Vorfreude war groß, hatten wir doch die letzten Summits in bester Erinnerung ...

  • Fokussiere deine Verbesserungen

    21.09. / Arjan de Jong

    Wer in einem agilen Team gearbeitet hat weiß, dass fast jedes Team durch externe Gründe irgendwann zum Stillstand gebracht wird. Existierende Probleme werden in agilen Vorgehensweisen schnell sichtbar, da diese Vorgehensweisen in kurze Iterationen geliefert werden ...

  • Coding Standards und deren Anwendung

    12.09. / Christoph Gostner

    Sourcecode wird öfter gelesen als geschrieben. Dies ist eine Tatsache, die man nur schwer verneinen kann. Oft müssen neue Features implementiert werden, wobei erst die richtige Stelle gefunden werden muss, um diese umzusetzen ...