© DrHitch/Shutterstock.com
jQuery Mobile

3 Automatisches Testen


Bisher gingen wir von der testgetriebenen Entwicklung aus, wenn wir über Unit Tests gesprochen haben. In diesem Kapitel soll nun das Thema Testausführung von einer anderen Seite betrachtet werden.

Der testgetriebene Ansatz geht wie beschrieben davon aus, dass immer alle Tests ausgeführt werden. Ab einer bestimmten Menge von Unit Tests kann dies aber zum einen länger dauern und zum anderen schnell unübersichtlich werden.

Da man aber auf das Testen sämtlicher Komponenten nicht verzichten möchte, bietet sich der Ansatz des automatischen Testens in einer Continuous Integration-(CI-)Umgebung an. Ein solches CI-System ist Jenkins, das in Kapitel 3.2 vorgestellt wird.

Bevor wir jedoch auf das CI-System selbst eingehen können, müssen noch ein paar Grundlagen geschaffen werden, um die JavaScript-QUnit-Tests in einer solchen Umgebung (ohne Browseroberfläche und automatisiert) durchführen zu können.

Grundlegend gibt es zwei Möglichkeiten, dies zu tun. Die erste Möglichkeit ist es, auf dem CI-Test Browser zu installieren und diese dann fernzusteuern. Ein mögliches Framework, das dies erlaubt, ist js-test-driver. Die zweite Möglichkeit ist es, die QUnit Tests ohne vollständigen Browser headless ablaufen zu lassen. Eine solche Möglichkeit bietet PhantomJS, welches im Folgenden genauer vorgestellt wird.

3.1 Headless Testing mit PhantomJS

Kopflos (engl. headless) bezieht sich in diesem Fall nicht auf die Person, die die Tests schreibt, sondern auf den Browser, der in unserem Fall durch PhantomJS ersetzt wird. Headless bezeichnet in diesem Zusammenhang das Fehlen der grafischen Darstellung des Webseiteninhalts.

Da dies in einer automatisierten Umgebung ohnehin überflüssig wäre, ist es genau das, was wir benötigen. Bezogen auf unsere Unit Tests interessiert uns letztlich ja nicht die hübsche Darstellung, sondern das Testergebnis. Wir möchten wissen, welche Tests erfolgreich bzw. fehlerhaft durchlaufen wurden.

PhantomJS kann auf phantomjs.org heruntergeladen werden. Zum Zeitpunkt der Erstellung dieses Buches war die Version 1.9.7 aktuell. PhantomJS verwendet zur Steuerung JavaScript. Um jetzt also unsere bereits vorhandenen Testseiten in PhantomJS durchlaufen lassen zu können, benötigen wir ein JavaScript, das die Seite in PhantomJS lädt.

Da PhantomJS eines der gängigsten Werkzeuge für diese Aufgabe ist, haben bereits andere Entwickler einen Testrunner für PhantomJS geschrieben. Der, den wir verwenden wollen, ist auf Github unter https://github.com/jonkemp/qunit-phantomjs-runner.git zu finden. Wenn man den Installationspfad von PhantomJS mit in den Path aufnimmt, kann man mithilfe eines der Testrunner (runner.js oder runner-list.js), wie in Listing 3.1 gezeigt, auf der Kommandozeile Tests ausführen.

[PROJEKT-PFAD]\MobileTesting\public_html\tests>
phantomJS ..\js\libs\runner.js all_asserts.html

Took 18ms to run 7 tests.7 passed, 0 failed.

Listing 3.1: Ausführen von Tests über einen Testrunner mit PhantomJS

In Listing 3.1 wurden die Tests, die in der HTML-Datei all_asserts.html eingebunden sind, durchgeführt. Am Ende wird das Ergebnis ausgegeben, dass sieben Tests durchlaufen wurden, sieben davon erfolgreich und keiner fehlerhaft. Die sieben Tests sind in Wirklichkeit sieben Asserts in einem einzigen Test.

Wenn man nun genauere Angaben haben möchte, kann man den Testrunner runner-list.js verwenden, der Testname und Assert-Texte mit auflistet. Wie das für den gleichen Test aussehen würde, ist in Listing 3.2 zu sehen.

[PROJEKT-PFAD]\MobileTesting\public_html\tests>
phantomJS ..\js\libs\runner-list.js all_asserts.html

Testing most Asserts
✓ Der Wert der Variablen Zahl ist 222.
✓ Der Wert der Variablen zeichenkette ist gleich dem Wert zahl
✓ Die beiden Objekte und ihre inneren Strukturen sind gleich
✓ Wert und Typ der beiden Objekte ist gleich
✓ Die Werte der Objekte sind nicht gleich.
✓ Die Objekte sind nicht vollkommen gleich
✓ Die Variablen zahl und zeichen haben unterschiedlichen Typ

Took 62ms torun 7 tests. 7 passed, 0 failed.

Listing 3.2: Unit Test auf der Konsole mit „runner-list.js“

Hier wird zuerst der Testtext ausgegeben und danach die einzelnen Asserts mit dem jeweiligen Status ✓( oder ) sowie dem dazugehörigen Text.

Im Fehlerfall würde, wie in der Browservariante auch, eine Fehlermeldung ausgegeben.

3.2 Continuous Integration mit Jenkins

Das Konzept der kontinuierlichen Integration (Continuous Integration, CI), das ursprünglich aus dem Extreme Programming stammt, wird an dieser Stelle als bekannt vorausgesetzt, da allein dieses Thema mehrere Bücher füllen würde.

Oft ist in der Praxis auch von Nightly Build die Rede, und der CI-Server wird auch als Build-Server bezeichnet. In unserem Beispiel werden wir Jenkins als CI-Server einsetzen. Die jeweils aktuelle Version kann unter http://jenkins-ci.org/ heruntergeladen werden. Die Installation gestaltet sich recht einfach, weshalb hier nicht näher darauf eingegangen wird. Wenn die Installation erfolgreich abgeschlossen ist, lässt sich Jenkins unter http://localhos...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang