Seite 2: Wie es funktioniert ...

Inhaltsverzeichnis

recheck-web ist ein kostenloses Open-Source-Tool, das auf Selenium basiert. Es funktioniert nach dem
Golden-Master-Prinzip, was im Wesentlichen bedeutet, dass es beim ersten Durchführen des Tests eine Kopie der gerenderten Website erstellt, und nachfolgende Durchläufe des Tests vergleichen den aktuellen Zustand mit dieser Kopie (dem Golden Master). So kann der Test erkennen, ob sich die Website auf unerwünschte Weise verändert hat. So kann recheck-web nach der Änderung einer ID das entsprechende Element noch identifizieren, indem es einfach in den Golden Master (wo die ID noch vorhanden ist) schaut und das Element dort findet. Mit zusätzlichen Eigenschaften wie XPath, HTML-Name und CSS-Klassen identifiziert recheck-web das Element auf der veränderten Website und gibt es an Selenium zurück. Der Test kann dann wie bisher mit dem Element interagieren, und die Änderung werden einfach als solche gemeldet.

Golden-Master-basierte Tests haben im Allgemeinen zwei wesentliche Nachteile:

1. Es ist oft schwierig, irrelevante Änderungen zu ignorieren. Viele Änderungen sind uninteressant und problemlos (z.B. Zeit- und Datumsänderungen sowie Zufalls-IDs). Aus dem gleichen Grund, aus dem Git die .gitignore-Datei verwendet, um Log-Dateien und andere temporäre und uninteressante Dateien und Artefakte zu ignorieren, nutzt recheck-web die recheck.ignore-Datei. Und mit einer Git-ähnlichen Syntax ist es einfach festzulegen, welche Unterschiede ignoriert werden sollen.
2. Es ist oft umständlich, Redundanzen zu pflegen. Mehrere Golden Master haben oft eine gewisse, teilweise sogar eine hohe Überschneidung. Dann ist die gleiche Änderung mehrfach zu prüfen und zu bestätigen, was die bei der einfacheren Testerstellung erzielte Effizienz schnell zunichte macht. recheck-web kommt mit einer eigenen CLI, die sich um diese lästige Aufgabe kümmert. Mit ihr (oder der kommerziellen GUI) können Nutzer dieselbe Änderung für dasselbe Element auf alle Golden Master oder einfach global alle Änderungen anwenden oder ignorieren.
   

Das Beispiel zeigt beide Nachteile: Die geänderte ID wurde nicht angezeigt, da in der recheck.ignore-Datei das ID-Attribut über attribute=id als ignoriert angegeben wurde. Das Entfernen dieser Regel führt dazu, dass der Test fehlschlägt – obwohl er nicht bricht. Das heißt, der Test wird weiterhin ausgeführt und die geänderte ID als solche angezeigt. Der obige Test verwendet den impliziten Prüfmechanismus, der nach jeder Aktion automatisch das Ergebnis überprüft. Das Öffnen der URL, die Eingabe des Benutzernamens und die Eingabe des Passworts sind drei Aktionen, die auf derselben Seite durchgeführt werden. Somit wird die geänderte ID dreimal angezeigt. Alle drei Instanzen lassen sich mit einem einzigen Aufruf von recheck commit --all tests.report auf der Kommandozeile behandeln. Die Änderung führt dazu, dass nun auch der recheck-web-Test fehlschlägt, da die ID aus dem Golden Master entfernt wurde.

Das verlangt nach einem weiteren Feature von recheck-web – der retestId. Die Grundidee ist es, ein zusätzliches Attribut in die Kopie der Website einzufügen. Da es nur in der Kopie und nicht auf der eigentlichen Website vorhanden ist, kann es von Änderungen nie betroffen sein (es sei denn, das Element wird vollständig entfernt). Man nennt das eine virtuelle konstante ID. Auf diese retestId lässt sich nun im Test Bezug nehmen. Entwickler müssen einfach den Aufruf von zum Beispiel By.id("username") durch By.retestId("username") ersetzen, und das Problem ist gelöst. Der Kniff adressiert auch Fälle, in denen Elemente schwer zu referenzieren sind, da sie gar keine HTML-ID haben.

Golden-Master-Testing als neues Verständnis von Testautomatisierung

Regressionstests finden keine Fehler in einem System. Damit sind sie keine Tests im eigentlichen Sinne. Sie schützen existierende Funktionen vor unerwünschten Seiteneffekten durch Änderungen. Damit sind Regressionstests ein Werkzeug zur Kontrolle von Änderungen. Es gibt bereits ein System, das diesen Zweck erfüllt: das Versionskontrollsystem. Allerdings verwaltet es nur statische Artefakte wie Code und Konfigurationsdateien. Das Verhalten der Software entsteht aber zur Laufzeit.

Diese Lücke schließt man mit automatischen Tests, die das Laufzeitverhalten der Software prüfen. Wie die Testpyramide (Mike Cohn, Succeeding with Agile, 2009) rät, sollten aber für User Interfaces so wenige Tests wie möglich automatisiert werden, da diese viel Aufwand bedeuten, langsam und brüchig sind. Zumindest zwei der drei Annahmen lassen sich mit dem Prinzip der Golden-Master-basierten Tests abschwächen: Sie sind einfacher zu erstellen und deutlich robuster.