Selenium

Der Vortragende Neal Ford ist von ThoughtWorks, der Vortrag auf englisch.

Selenium ist ein funktionales Open-Source Testtool für Webanwendungen, geschrieben in JavaScript.

Man schreibt die Tests ähnlich wie bei FIT-Action-Fixtures auf. Ausgeführt wird der Test im Browser. Dabei wird alles mögliche unterstützt, z.B. auch Popup-Fenster.

Im Test muss man natürlich die Elemente auf der HTML-Seite adressieren. Das geht über IDs und Namen und den DOM. Letzteres braucht man vor allem für Elemente, denen man keine IDs gibt, wie z.B. Ausgabetabellen.

Es gibt ein Firefox-Plugin namens XPather: Damit clickt man auf ein Element auf der Seite und bekommt den DOM-Pfad angezeigt, den man dann in den Test einpasten kann.

Bei der String-Prüfung werden auch Wildcards und Regexps unterstützt.

Das Adressieren der Elemente und die Prüfung der Seiteninhalte ist also sehr flexibel.
AJAX geht auch.

Es gibt ein paar Geschichten, die doch nicht gehen: z.B. wenn man in Java-Script als Reaktion auf onload einen Dialog öffnet. File-Upload funktioniert nur in Firefox.

Variablen werden unterstützt. So kann man einen Wert, den die Anwendung generiert, in einer Variablen starten und woanders wieder einfügen. Variablenwerte kann man auch durch JavaScript berechnen lassen.

Der Referent rät dazu, hart-codierte Werte in Akzeptanztests zu vermeiden. Ich habe aber nicht verstanden, wie er die umgeht.

Selenium lässt sich in automatic-builds integrieren. Dazu muss man anscheinend nur den Browser mit der URL des Tests aufrufen. Ich bin nicht ganz sicher, aber es scheint so, dass Selenium das Ergebnis dann an den Integration-Server POSTet.

Normalerweise muss man die Anwendung zum Testen serverseitig mit dem Browser-Bot starten. Mit Remote-Control-Selenium braucht man das nicht und kann so Seiten testen, die dafür nicht vorbereitet sind (z.B. Google). Das läuft über einen Proxy-Server. Damit kann man nicht nur die Tests ausführen, sondern auch über die Kommdozeile die Web-Anwendung fernzusteuern. Also kann man die Selenium-Tests auch als JUnit-Tests oder in Ruby oder sonstwas schreiben. Jetzt zeigt er einen Selenium-Test in JUnit. Das sieht eher unübersichtlich aus - die HTML-Version des Tests ist übersichtlicher. Vielleicht helfen beim JUnit-Test auch ein paar Extract-Methods.

"Web Developer Toolbar"-Plugin für Firefox und Internet-Explorer ist nützlich.

Es gibt eine Selenium-IDE als Firefox-Plugin. Damit kann man Tests aufzeichnen und wieder ausführen. In dem Test gibt es natürlich kaum Asserts. Die fehlenden Asserts kann man direkt in der IDE ergänzen. Da gibt es auch Auto-Completion. Den aufgezeichneten Test kann man als HTML-Test oder JUnit-Test oder, oder, oder exportieren.

Jetzt wird gezeigt, wie man eine Google-Maps-artige AJAX-Anwendung testet - Selenium kann alles testen, wo man draufclicken kann. Beeindruckend!

So gehen sie bei Thought-Works vor: Wenn eine Story implementiert ist, zeichnet der Business-Expert den Durchlauf durch die Anwendung auf und die Entwickler ergänzen fehlende Asserts.

In Kürze soll eine Integration mit FIT kommen.

Es wird gefragt, wie es mit der Wartbarkeit der Tests steht: Neal exportiert die Tests nach Java bzw. Ruby und bearbeitet sie dort weiter. Ohne diese "Aufarbeitung" sind die Tests sehr fragil.

Man kann HTML und JavaScript testen, aber kein Flash, ActiveX etc. iFrames gehen aber. Für HTTPS muss man das Zertifikat einmalig importieren.

Load-Testing geht (noch) nicht. "We kill only one Mercury product at a time."

(Der Referent benutzt nicht nur einen Mac, sondern auch IntelliJ - sonst sieht man ja immer nur Eclipse.)

Fazit
Selenium ist sehr mächtig. Das bezahlt man mit Komplexität. Die Tests, die man als Web-Seiten beschreibt wirken fast wie eine eigene Programmiersprache. Ich kann mir nicht vorstellen, dass Anwender solche Tests selber schreiben. Sie können sie aufzeichnen, aber anschließend nicht mehr warten / verstehen.

Für Tests, die die Entwickler schreiben, ist Selenium sicher interessant.