In unserem aktuellen Projekt werden ziemlich viele Selenium Tests erstellt und ausgeführt. Selenium Tests bedürfen einer besonders Intensiven Wartung und Pflege. Der Kunde wünschte sich ein Monitoring über den Zustand der Tests in zeitlicher Hinsicht. Jenkins bietet einige Plugins zur Visualisierung an, aber das reichte uns nicht. Ziel war es eine Gesamtsicht  und Einzelsicht auf alle Test Module zu haben. Bei jeden Test sollte erkennbar sein bei welchen Build Lauf er erfolgreich war oder nicht.

UnitTH ist ein kleines Java Tool das aus den Unit Test Ergebnis Dateien einen Report erzeugen kann.

Das Tool untersucht bestehende Unit Test Report XML Dateien und erzeugt daraus ein einen Report. Die zeitliche Achse wird durch Build Läufe erzeugt. UnitTH erkennt die Build Läufe anhand von Ordnern.

Die Reports muss in dieser Struktur vorliegen:

/build1/junit_log1.xml
/build1/junit_log2.xml
/build2/junit_log1.xml
/build2/junit_log2.xml

In den Ordnern können beliebig viele XML Dateien liegen.

Testsuiten sind für das Tool sogenannte Module. Damit wird der Report gegliedert. Man muss also darauf achten das die Suiten in den Reports eindeutige Namen haben und nicht verschachtelte Suiten haben. Meine Report Dateien haben nicht ganz dem Schema entsprochen. Ich wandel die Dateien mit XSLT um.

Der Aufruf erfolgt so:

java -jar -Dunitth.report.dir=/…/unitth/report unitth.jar /…/unitth/xml/*

Man gibt also nur das Ziel Verzeichnis für die Reports und den Pfad zu den XML Dateien.

In den Report bekommt man eine praktische Übersicht über den aktuellen Stand der Tests und den Trend.

Über die Graphen kann man erkennen, wie sich die Testdauer verhält und ob sich die Anzahl der Tests verändert.

Man bekommt eine Liste der Build Läufe und darin zusammengefasst wie deren Status war. Hier sieht man auch schön die aktuellen Trends.

Die Module (Testsuiten) werden auch zusammengefasst dargestellt und man kann sich auf einer Unterseite den Verlauf auf Testcase Basis anschauen. Dadurch kann man besonders kritische Testfälle erkennen und dann stabilisieren.

Das spannendste Feature ist die Spread Ansicht. Hier sieht man, bei welchen Build die Testfälle fehlgeschlagen sind. Damit kann man sogenannte "Blinker" Test finden. Um diese dann zu Isolieren.

Eine Versionsverwaltung gehört mittlerweile zu fast jeden Software Projekt. Für Webeprojekte nutze ich gerne den Anbieter Springloops. Dieser bieten für wenig Geld einen Subversion Server und eine schicke Oberfläche für das Deployment. Wunderbar ist auch die Möglichkeit eines Rollbacks, die ich schon des öfteren benutzt habe.

Seit kurzem haben die Macher von Springloops das Automatische Deployment eingebaut. Man kann jetzt individuell für jeden Ziel Server einstellen ob die aktuellste Version automatisch oder manuell deployed werden soll.

Besonders praktisch ist das, wenn man einen Testserver aufgesetzt hat. Normalerweise setzte ich immer einen Test Server und einen Live Server in Springloops auf. Das geht auch mit ganz simplen Webhosting Packeten. Einfach ein anderes Zielverzeichniss auf den Server auswählen und eine Test Domain darauf konfigieriern.

Bei diesen Testserver macht ein automatisches Deployment Sinn und spart die Klickerei. Man kann es auch gut für die Continuus Integration verwenden wenn man auf diesen Testserver Per Cronjob regelmäßig die Tests ablaufen lasst.

Das schöne an Springloops ist dass man keinerlei Administratoren Kenntnisse braucht und auch keinen eigenen Webserver mit Root Rechten.