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.

In diesen Artikel geht es darum wie Selenium Grid installiert wird.

Wozu Selenium Grid?

Man kann Selenium Tests über einen Selenium RC Server automatisiert ausführen. Wer das schon mal gemacht hat, weiß das dieser Prozess sehr lange dauern kann. Insbesondere wenn man verschiedene Browser testen möchte und die Tests mit Dataprovidern verwendet. Das bedeutet das die Tests nicht nur einmal, sondern mehrmals laufen und dann kommen schnell ein paar Stunden zusammen. Diese Zeit ist besonders unangenehm wenn man die Software ausliefern möchte und lange auf die Test Ergebnisse warten muss.

Selenium Grid behebt das Problem in dem es wie eine Art Load Balancer arbeitet. Es existiert ein Hub der genau wie der RC Server die Test Kommandos entgegen nimmt.  Der Hub verhält sich für den Test Client (z.Bsp.: PHPUnit) genauso wie der Selenium RC Server. An den Hub können sich verschieden RC Server Instanzen registrieren. Diese Server können auch auf ganz anderen Host Systemen oder Virtuellen Hosts laufen. Somit kann man auch wirklich alle Browser Varianten testen.

Installation

Man benötigt einen Host der vom Test Client erreichbar ist. Also der Rechner auf der PHPUnit oder JUnit läuft. Auf diesem Host muss Ant installiert sein um den Grid Hub zu starten. Selenium Grid muss man nur herunterladen und entpacken.

Hub Starten

Zum Starten des Hubs wechselt man ich den Grid Verzeichniss und startet den Hub über die buid.xml

ant launch-hub

Damit ist der Hub auf diesen Host unter localhost:4444 erreichbar.

RC Server starten

Den RC Server kann man entweder auf dem dem gleichen Host starten.

ant launch-remote-control -Dport=5555

oder auf einen anderen Host oder VHost

ant launch-remote-control -Dport=5555 -Dhost=vhost1 -DhubURL=http://grid-hub:4444

Host: Das ist die Adresse vom Hub aus gesehen zum Host auf dem der RC Server liegt.

HubUrl:  Das ist die Adresse zum Hub vom Host mit dem RC Server.

Sinnvollerweise betreibt man die RC Server auf getrennten Hosts.

RC Server Einstellungen

Man kann den RC Server der unter Grid läuft genauso anpassen wie einen normalen RC Server. Um beispielsweise ein spezielles Firefox Profil zu verwenden kann man beim Starten des RC Servers noch das Selenium Argument firefoxProfileTemplate mit dem Ant Property seleniumArgs angeben.


ant launch-remote-control -Dport=5555 -DseleniumArgs="-firefoxProfileTemplate C:\selenium_ff"
Umgebungen
Der RC Server unter Grid läuft im Gegensatz zum normalen RC Server immer nur mit einer Umgebung. Standardmäßig ist das "*firefox". Um eine andere Umgebung zu starten muss das Argument environment angeben.
-Denvironment="*iexplore"

PHPUnit und Grid
Leider ist es nicht möglich den vollen Nutzen aus Grid zu ziehen wenn man mit PHPUnit arbeitet. Da PHPUnit nicht in der Lage ist die Tests parallel auszuführen.
Man kann aber dennoch die Tests mit dem --filter oder --group Argument aufteilen und diese dann parallel ausführen. Hierbei muss man aber dann die Ergebnisse aus den verschiedenen Ausführungen zusammenfassen.
Auf jeden Fall lohnt sich aber die Aufteilung für verschiedene Browser.
Absolut notwendig wird Grid wenn man verschiedene Build Prozesse hat die einen Selenium Server nutzen.
Fazit
Grid lässt sich relativ einfach aufsetzen und erhöht die Test Performance deutlich.
							

Die Selenium-RC Version 1.0.1 ist leider nicht kompatibel mit dem neuen Firefox 4.

Das Selenium Server Paket enthält einige Firefox Erweiterungen in denen eine maximale Kompatibilität zu Firefox 3.5 angegeben wurde. Diese Erweiterungen sind auch mit der Version 4 lauffähig, doch man muss die install.rdf Dateien anpassen.

Anleitung zum modifizieren des Selenium RC

1. Entpacke das Java Archiv selenium-server.jar
2. Suche alle Dateien mit dem Namen install.rdf in dem ausgepackten Verzeichnis.
3. Ändere in den Dateien den Wert <em:maxVersion>3.5.*</em:maxVersion> auf <em:maxVersion>4.*</em:maxVersion>
4. Erzeuge eine neue jar Datei
   1. Gehe in der Kommando Zeile in das ausgepackte Verzeichnis
   2. Stelle sicher dass das JDK im Pfad vorhanden ist.  (PATH=C:\Programme\Java\jdk1.6.0_18\bin)
   3. Erzeuge die neue Jar Datei: jar -cvfm selenium-server.jar META-INF/MANIFEST.MF *
5. Tausche die alte selenium-server.jar mit der neuen aus.

Ich nutze die Eclipse PHP Tool Integration Tools jetzt standardmäßig wegen der guten  Code Sniffer Integration wie bereits in einen älteren Blogbeitrag beschrieben.

Darüber hinaus beinhaltet das Eclipse Plugin auch eine Funktion zum schnellen Ausführen von Unit Tests.

Wenn man an einen Unit Test arbeitet kann man einfach einen Button im Eclipse anklicken zum Ausführen des Tests.

Erstmal ist das relativ unspannend, da das selbe passiert wie bei einem Kommandozeilen Aufruf und die Ausgabe nur  unschön in der Eclipse Console erscheint.

Es spart aber immerhin einen Toolwechsel und einige Klicks.

Wirklich praktisch finde ich aber die Auswertung der Fehler im Editor von Eclipse. Dort wird die Stelle wo der Fehler aufgetreten ist als unterstrichener Fehler markiert.

Es wird nicht nur die Stelle im Test markiert sondern Fehler die in den getesteten Code Aufgetreten sind. Wenn dort ein PHP Fehler auftritt oder eine Exception geworfen wird die nicht abgefangen wird, wird diese Stelle markiert. So braucht man nicht anhand der Zeilen Nummern die Stellen suchen.

Bei der Erstellung der Codecoverage mit phpUnit bin ich schon mehrmals aus diesen PHP Fehler gestoßen:

PHP Fatal error:  Cannot redeclare class

Aus dem Code war kein Grund dafür ersichtlich da alle Dateien mit require_once eingebunden waren. Das Problem lag dabei in der Verwendung von Mock Klassen ohne diese vorher importiert zu haben.

Ich kann mit folgenden Code eine Object der Klasse Example erstellen ohne die original Klasse zu laden.

$object = $this->getMock ( 'Example', array (), array (), '', false );

Wenn danach die original Klasse Example importiert wird, ist diese schon deklariert und es kommt zu diesen Fehler. Abhilfe tut hier ein require_once im Test:

require_once('path/to/Example.php');
$object = $this->getMock ( 'Example', array (), array (), '', false );

Dann klappt es auch mit der Coverage Auswertung.

Mit Mock Objekten kann man in Unit Test wunderbar Verhalten von Klassen simulieren, die außerhalb des Test Kontext liegen. Man kann zwar Methoden überschreiben und deren Rückgabewert selbst definieren.

$configuration = $this->getMock('Configuration',array('get'));
$configuration ->expects($this->any())
	->method('get')
	->with($this->equalsTo('key1'))
	->will($this->returnValue('value1'));

Dieses erzeugt ein Ojekt vom Typ  Configuration, welche bei der Methode get mit dem Parameter key1 den Wert value1 zurückgibt.

Dieses Beispiel verdeutlicht auch gleich das Problem, wenn ein Mock-Objekt bei unterschiedlichen Parametern unterschiedliche Werte zurückgeben soll. Genau das ist mit dieser Methode nicht möglich.

Folgendes Beispiel geht nicht:

$configuration = $this->getMock('Configuration',array('get'));
$configuration ->expects($this->any())
	->method('get')
	->with($this->equalsTo('key1'))
	->will($this->returnValue('value1'));

$configuration ->expects($this->any())
	->method('get')
	->with($this->equalsTo('key2'))
	>will($this->returnValue('value2'));

Callback nutzen.

Statt mit returnValue kann man in phpunit auch mit returnCallback arbeiten und ein wenig Logik in das Mock Objekt einbauen.

$configuration = $this->getMock('Configuration',array('get'));
$configuration ->expects($this->any())
	->method('get')
	->will($this->returnCallback(array($this,'getMockConfig')));

In der passenden Methode kann man die Logik einbauen:

public function getMockConfig($value){
	switch($value){
		case 'cache_backend':
			return 't3lib_cache_backend_File';
			break;
		case 'cache_backend_config':
			return 'defaultLifetime:3600;';
			break;
		case 'cache_frontend':
			return 't3lib_cache_VariableCache';
			break;
		default:
			return 'txefttestcache';
			break;
}