recheck-web – ein etwas anderer Ansatz zur Testautomatisierung
Automatisierte Tests sind schwer zu erstellen, oft fragil und unvollständig. Recheck/review reagiert darauf mit einem neuen Testparadigma.
Recheck/review verfolgt den Ansatz der vergleichenden Prüfung, das heißt des Aufdeckens relevanter Unterschiede. Anstatt Spezifikationen (assertions) zu erstellen und immer wieder anzupassen, werden bei minimalem manuellem Aufwand ganze Webseiten durch recheck vergleichend überprüft. Das Produkt stellt eine effiziente, intuitive und benutzerfreundliche grafische Oberfläche zur Verfügung, die die Einarbeitung verkürzt und es Benutzern ermöglicht, ihre Tests bei Änderungen mit wenigen Klicks anzupassen.
GUI-Testautomatisierung steckt derzeit in einer Sackgasse. Tests werden aufwendig manuell erstellt und gepflegt, gehen oft schief und liefern zu viele falsch positive Ergebnisse. Wenn der Entwickler bestimmte Elemente oder Attribute nicht spezifiziert, werden sie nicht überprüft.
Diese leidige Problemstellung mit der Web-Entwickler und Tester sich täglich herumschlagen müssen, lenkte die Entwicklung von recheck/review. Recheck überprüft jede Codezeile einer Webpage und erstellt eine Referenzvorlage, auch Golden Master genannt. Vielfältiger Abgleich mit diesem Golden Master führt auf ein Verfahren mit dem die Testerstellung und vor allem die Pflege der Tests einfacher als je zuvor wird. Rechecks bessere Elementerkennung macht Tests robuster und reduziert die falsch positiven Ergebnisse. Das heißt, wenn recheck Fehler zeigt, dann sind es Fehler.
Mit Review steht Entwicklern eine intuitiv benutzbare Steuerung zur Verfügung. Ihr patentierter 1-Klick-Mechanismus macht Tester in wenigen Stunden produktiver.
Recheck/review ist ein voll funktionsfähiges eigenständiges Produkt, das offline funktioniert. Testwartung für Webapplikationen verliert seine Schrecken. Der Ansatz des Differenztests vervollständigt die Testautomatisierung und macht Regressionstests robuster und effizienter.
recheck-web ist ein Golden-Master-basiertes Testwerkzeug. Da es im Prinzip gerenderte Webseiten miteinander vergleicht, lassen sich damit auch Cross-Browser-Testing, Cross-Platform-Testing und andere Testszenarien umsetzen.
Um eine Anmeldung einer Webanwendung zu testen, könnte ein typischer Selenium-Test etwa so aussehen:
Das ist ein einfacher Test, der eine bestimmte URL öffnet, dann Eingabefelder anhand ihrer unsichtbaren Element-IDs findet, um Benutzernamen und Passwort einzugeben, und schließlich auf Login klickt. Wie derzeit üblich, verwendet der Test am Ende eine Unit-Test-Bibliothek, um das korrekte Ergebnis der Testausführung mit einer “assert”-Anweisung zu überprüfen. Konkret wird geprüft, ob der Text “Success!” angezeigt wird.
Die im Artikel verwendeten Beispiele finden sich auf GitHub. Zur Verwendung und Installation der gezeigten Werkzeuge finden Sie hier ein ausführliches Tutorial: Zum Tutorial
Jetzt können Entwickler das HTML der zu testenden Website ändern. Sie könnten zum Beispiel die CSS-Deklaration
<link href=”./files/main.css” rel=”stylesheet”> bearbeiten. Das Ändern eines einzelnen Zeichens der URL führt dazu, dass die Website ohne Formatierung angezeigt wird.
Nun ist es an der Zeit, den Originaltest zu nehmen und den Selenium-Treiber in einen RecheckDriver zu stecken:
driver = new RecheckDriver(new ChromeDriver());
Bei entsprechender Projektkonfiguration ist sonst nichts weiter nötig. Die Prüfung mittels assert kann man nun löschen. Entfernt man das CSS von der Website, schlägt der Test plötzlich mit vielen Unterschieden fehl.
Wie es funktioniert …
recheck-web basiert auf 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:
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.
Es ist 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 einfacher mit dem grafischen Interface, 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.
Filter-Mechanismus als wichtigste Zutat
Was wäre Git ohne die .gitignore-Datei? Das Ausfiltern irrelevanter Änderungen ist eine der wichtigsten Fähigkeiten eines Versionsverwaltungssystems. Wenn man nun Golden-Master-Testing als entsprechende Erweiterung versteht, ist das Ausfiltern dieser Änderungen auch hier von enormer Bedeutung. Traditionelle Assertion-basierte Tests ignorieren mehr als 99 Prozent der Änderungen. Stattdessen, ähnlich wie bei Git ohne .gitignore-Datei, wird recheck-web jede Änderung melden. Es liegt also am Nutzer, Änderungen zu ignorieren, die für ihn nicht von Interesse sind.
recheck-web kann für Cross-Browser-Testing, Cross-Device-Testing, Deep-Visual- sowie funktionales Regressionstesten verwendet werden – je nachdem, was man ignoriert oder eben nicht.
Der Filtermechanismus ist gleichermaßen einfach (angelehnt an die .gitignore-Datei) wie mächtig. So lassen sich einzelne Attribute global oder für bestimmte Elemente filtern sowie einzelne Elemente komplett oder sogar ganze Teilbereiche der Seite ignorieren. Und wem das noch nicht reicht, der kann Filterregeln in JavaScript implementieren und so etwa unterschiedliche URLs mit gleicher Basis oder Positionsunterschiede kleiner fünf Pixel ignorieren.
Ein guter Ausgangspunkt zum Verständnis sind die vordefinierten Filterdateien, die recheck-web mit ausliefert. So ist das Ignorieren der Elementpositionierung in der Regel eine gute Idee. Wenn die Leser mehr darüber erfahren möchten, wie sie ihre recheck.ignore-Datei pflegen oder eigene Filter erstellen können, sollten sie die Dokumentation lesen.
Fazit
recheck-web ist eines der wenigen Golden-Master-basierten Testwerkzeuge. Es bietet die Möglichkeit, schnell und einfach Tests zu erstellen, die vollständiger und robuster sind als herkömmliche Tests. Da es im Prinzip gerenderte Webseiten (oder Teil davon) miteinander vergleicht, lassen sich damit auch Cross-Browser-Testing, Cross-Platform-Testing und andere Testszenarien realisieren.