Quick Win: Javascript Tests in Jenkins integrieren

„untested code is broken code“

Nicht nur Hardliner werden zustimmen. Natürlich gilt das auch für Javascript, insbesondere da heutzutage viel Logik in den Client verlagert wird.

Tests für Javascript-Code lassen sich recht einfach z.B. mit qunit schreiben. Der Testcase ist dann eine HTML-Datei, die Javascript enthält und einfach im Browser geöffnet werden kann. Man sieht dort direkt, ob der Test durchgelaufen oder fehlgeschlagen ist.

Nun sollen diese Tests auch in den kontinuierlichen Build-Prozess integriert sein, da wohl kaum jemand die Tests ständig per Hand aufrufen will. In unserem Fall integrieren wir die Tests dafür in Jenkins.

Hier kommt phantomjs ins Spiel. PhantomJS ist ein Webkit basierter Browser, der für eine “Headless”-Umgebung, also ein System ohne graphische Ausgabe, entwickelt wurde.

PhantomJS lässt sich per Javascript steuern. Mitgeliefert wird ein Skipt “run-qunit.js”, welches unseren Testcase (also die HTML-Datei) öffnet und das Testergebnis aus der Seite ausliest. Das Skript erzeugt dann eine entsprechende Ausgabe des Testergebnisses auf der Konsole und setzt den Exit-Code von Phantomjs passend zum Testresultat.

Als erstes legen wir ein neues Build-Target für die Javascript-Tests an:

<target name="qunit" description="qunit javascript tests via phantomjs">
  <property name="phantomjs.exe.file" value="/usr/local/bin/phantomjs" />
  <property name="run-qunit.js.file" value="${source}/tests/javascript/run-qunit.js" />       
  <apply           
    executable="${phantomjs.exe.file}"           
    verbose="true"           
    failonerror="true"           
    failifexecutionfails="true"       
  >           
    <arg value="${run-qunit.js.file}"/>           
    <fileset dir="${source}/tests/javascript/tests/">               
      <include name="**/*.html" />           
    </fileset>       
  </apply>   
</target>

Das Target führt alle HTML-Dateien unterhalb von tests/javascript/tests mit Phantomjs aus. Wichtig ist beim apply-Element das Attribut “failifexecutionfails”. Es sorgt dafür, dass der Build fehlgeschlägt, wenn phantomjs einen Fehler meldet, also wenn ein Test fehlgeschlagen ist.

Die Property “phantomjs.exe.file” zeigt auf die ausführbare phantomjs, die wir vorher installiert haben. Die Property “run-qunit.js.file” zeigt auf das oben erwähnte Skript, welches wir zu unseren Tests gelegt haben.

PhantomJS braucht einen virtuellen Framebuffer (xvfb). Diesen binden wir auf DISPLAY :99 und tragen dafür auf dem Jenkins-Server folgendes Init-Skript in die entsprechenden Runlevel ein (Wie das genau funktioniert, das sollte für den jeweiligen Server geprüft werden. Dieses Skript dient der Veranschaulichung):

#!/bin/bash
### BEGIN INIT INFO
# Provides:          Xvfb
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start Xvfb buffer for display 99
# Description:       Start Xvfb buffer for display 99 for jenkins phantomjs builds
### END INIT INFO

if [ -z "$1" ]; then
echo "`basename $0` {start|stop}"
exit
fi

case "$1" in
start)
/usr/bin/Xvfb :99 &
;;

stop)
killall Xvfb
;;
esac

Anschließend braucht Jenkins noch die Info, dass wir DISPLAY :99 benutzen wollen, was man einfach über die Konfigurationsoberfläche einstellen kann:

Ein anderer Ansatz, der auch Fehler in den verschiedenen Browsern aufdecken kann, wäre z.B. JsTestDriver. Doch dazu mehr ein anderes Mal.