Website-Layout-Regressionstests mit Docker-Console

Ist es Ihnen schon einmal passiert, dass Sie auf einer Website nachgeschaut haben und sich nicht sicher waren, ob eine von Ihnen verwendete Schriftart 12 pt oder 13 pt groß war? Oder vielleicht haben Sie sich ein Bild immer wieder angesehen und sich gefragt, ob es vorher leicht nach links verschoben wurde? Wenn das Layout auf Ihrer Website Priorität hat, ist es vielleicht an der Zeit, über die Automatisierung der Überprüfung dieses Aspekts Ihres Projekts nachzudenken. VisualCeption ist eine bemerkenswerte Lösung für genau diesen Anwendungsfall. Bei Droptica nutzen wir es häufig, um sicherzustellen, dass die Unternehmenswebsites, die wir für unsere Kunden erstellen, die ursprüngliche Qualität während der nachfolgenden Entwicklungsiterationen erhalten bleiben. 

In diesem Artikel zeigen wir Ihnen, wie Sie dieses Add-on auf einem mit der docker-console erstellten Projekt starten. Genau wie in unseren vorherigen Artikeln basieren unsere Beispiele auf dem Projekt, das Sie bereits aus unseren vorherigen Beiträgen kennen.

Wie funktioniert es?

Beim ersten Start erstellt VisualCeption einen „Referenz“-Screenshot einer gegebenen Website oder einer im Test angegebenen Liste von Elementen. Dann, bei jeder nachfolgenden Ausführung des Tests, nimmt VC neue (aktuelle) Screenshots und vergleicht sie mit den vorherigen Versionen – weshalb die erste Ausführung immer mit einem positiven Ergebnis endet, da es keine Basisdateien gibt, mit denen es den aktuellen Zustand der Seite vergleichen könnte. Dieser Vergleich ergibt einen Prozentwert, der die Unterschiede zwischen den beiden Bildern ausdrückt, und eine Datei, die angibt, wo sich die Änderungen befinden. All das mag jetzt etwas unklar erscheinen, aber ich hoffe, dass alles klar wird, sobald wir am Ende des Artikels angelangt sind. Also, ohne weiteres, lassen Sie uns zur Konfiguration übergehen.

Neue Test-Suite

Da diese Art von Tests eher langsam ausgeführt wird, halten wir es für angebracht, eine neue Test-Suite zu erstellen, um die verbleibenden Tests nicht zu verlangsamen und besseren Überblick über alle Tests zu behalten. Um dies zu tun, öffnen Sie das Terminal (im Projektordner) und geben Sie ein:

dcon codecept generate:suite visual

Nach Ausführung dieses Befehls werden die für das Starten der Tests in der neuen Suite erforderlichen Dateien automatisch in unserem Projekt erstellt. Wahrscheinlich müssen wir die Berechtigungen und den Besitzer ändern, da Root-Dateien erstellt werden.

Installation

Wenn Sie dem Link zum Projekt folgen (https://github.com/Codeception/VisualCeption), sehen Sie, dass es notwendig ist, VisualCeption der composer.json hinzuzufügen; jedoch können Sie diesen Schritt sicher überspringen, wenn Sie die docker-console verwenden. Stellen Sie sicher, dass Imagick auf Ihrem Computer installiert ist (https://www.imagemagick.org/script/index.php) – es wird zum Vergleich von Screenshots verwendet. Nun ist es Zeit, das Modul in visual.suite.yml freizuschalten. Hier müssen wir auch Webdriver hinzufügen (da es zur Automatisierung von Webbrowsern verwendet wird), sodass Ihre Konfigurationsdatei am Ende ähnlich wie die unten dargestellte aussehen sollte:

Sie können die folgenden Parameter in der VisualCeption-Konfiguration einstellen:

• referenceImageDir – VisualCeption speichert die vorherigen Screenshots, um etwas zu haben, das mit dem aktuellen Zustand der Seite verglichen werden kann. Standardmäßig erstellt es einen neuen Ordner namens „VisualCeption“ in tests/_data.
• currentImageDir – bei jeder nachfolgenden Ausführung des Tests erstellt VC neue Screenshots, die mit den Referenzscreenshot verglichen werden, standardmäßig befinden sie sich in tests/_output/debug/visual/
• maximumDeviation – beim Vergleich von zwei Screenshots berechnet VC den prozentualen Unterschied zwischen den Bildern. Dieser Parameter gibt an, wie groß der Unterschied sein darf, ohne dass ein Fehler ausgegeben wird. Standardmäßig ist er auf 0 gesetzt, was bedeutet, dass selbst die geringste Änderung zu einem Fehler führt.
• saveCurrentImageIfFailure – Wenn dieser Wert auf wahr gesetzt ist, wird bei einem Testfehlschlag der aktuelle Zustand des Bildschirms in einer Datei mit dem Präfix „current“ gespeichert.
• report – standardmäßig ist diese Option auf false gesetzt, aber sobald Sie sie aktivieren, wird bei jedem Fehlschlag ein HTML-Bericht in tests/_output/vcresult.html generiert. Wir werden Ihnen später zeigen, wie es aussieht.
• module – Diese Einstellung bestimmt, welches Modul für die Interaktion mit dem Browser verantwortlich ist. Standardmäßig ist es WebDriver.
• fullScreenShot (Standard: false) Ganzseitenscreenshot für Chrome und Firefox.
• templateFile - absoluter Pfad oder relativ vom Moduldirektorium zur Berichtsvorlage, Standard "/report/template.php".

Chrome vs Firefox

Wie Sie bereits gesehen haben, verwenden wir bei der Durchführung von Tests mit WebDriver immer Chrome; in diesem Fall empfehlen die Autoren von VisualCeption jedoch die Verwendung von Firefox.

Wir werden dieser Empfehlung folgen, um Ihnen zu zeigen, wie Sie Firefox in Ihren Tests verwenden. Außerdem wird diese Konfiguration alle Fähigkeiten dieses Moduls demonstrieren, aber natürlich sind Sie frei, mit anderen Versionen von Selenium und verschiedenen Browsern zu experimentieren.

Wenn Sie Firefox als Standardbrowser für Ihr Projekt verwenden möchten, müssen Sie einige Änderungen an der Konfiguration Ihrer Umgebung vornehmen. Gehen Sie zunächst zum docker_console-Ordner und finden Sie dc_settings.py, wo Sie das Selenium-Image in das für die Tests verwendete ändern müssen.

 Die Zeile 'selenium_image': ('selenium/standalone-chrome', None), sollte ersetzt werden durch 'selenium_image': ('selenium/standalone-firefox:2.53.1', None). Wir werden mehr über die Konfiguration eines Projekts, um viele Selenium-Images verwenden zu können, in einem kommenden Artikel schreiben.

Da wir nun ein mit Firefox konfiguriertes und bereitgestelltes Selenium-Image haben, müssen wir auch den Browser in den Konfigurationsdateien der Test-Suiten, die Webdriver verwenden, ändern. In unserem Fall wird das visual.suite.yml und js_capable.suite.yml sein

In diesem Fall werden Ihre Tests mit Firefox durchgeführt. Nach dieser Änderung müssen Sie sicherstellen, dass die zuvor geschriebenen Tests noch ordnungsgemäß funktionieren, da es sich herausstellen kann, dass der Testcode ebenfalls einige Anpassungen benötigt – zum Glück verlief in unserem Beispielprojekt alles reibungslos und wir mussten hier nichts anpassen.

Wenn Sie dennoch Chrome für Ihre Tests verwenden und ein Ganzseitenscreenshot machen möchten, können Sie die fullScreenShot-Option in dieser Modulanwendung verwenden oder für jeden Test die Seitenhöhe dynamisch einstellen (es funktioniert mit dem Docker, wo die physische Größe des Bildschirms uns nicht begrenzt).

Verwendung in Tests

Die Nutzung dieses Moduls in Tests ist sehr einfach, da es hauptsächlich auf zwei zusätzlichen Funktionen basiert:

•  seeVisualChanges, die einen Fehler zurückgibt, wenn keine Unterschiede auf der Seite gefunden werden und
•  dontSeeVisualChanges, die einen Fehler zurückgibt, wenn irgendwelche Unterschiede auf der Seite sichtbar sind.

Beide Funktionen können mit unterschiedlichen Parametern verwendet werden, um besser festzulegen, was wir auf einer bestimmten Seite überprüfen möchten.

Deshalb werden wir, um die Seite auf für den Benutzer sichtbare Veränderungen zu prüfen, einen Test ähnlich dem unten geschriebenen erstellen:

 public function page(VisualTester $I) {
 	$I->wantTo('Test - Startseite vergleichen');
 	$I->amOnPage('/');
 	$I->dontSeeVisualChanges("homepage");
 }

In diesem Test wird der Parameter „homepage“ ein eindeutiger Name für den in dieser Datei aufgenommenen Screenshot sein, sodass VisualCeption weiß, welche zwei Dateien es vergleichen soll. Nach dem Ausführen des Tests erhalten wir einen Screenshot, der dem unten dargestellten ähnlich ist:

Wenn Sie einen Screenshot der gesamten Seite machen möchten, sollte der Test ähnlich wie der unten dargestellte aussehen:

 public function page(VisualTester $I) {
 	$I->wantTo('Test - Startseite vergleichen');
 	$I->amOnPage('/');
 	$I->dontSeeVisualChanges("homepage");
 }

Was wir hier gemacht haben, war, einen zweiten Parameter hinzuzufügen, einen „#page“-CSS-Selektor, der ein Container mit allen Inhalten auf der Seite ist. Die Unterschiede im zu vergleichenden Bereich werden leicht erkennbar sein, sobald Sie den diesmal gemachten Screenshot überprüfen. 

Mit dieser Methode können wir auch Änderungen in kleineren Elementen der Seite wie dem Header oder Footer nachverfolgen.

Eine weitere Möglichkeit, die VisualCeption bietet, ist das Ausschließen von Elementen, die wir nicht auf der Seite verfolgen möchten. Dies ist eine sehr hilfreiche Funktion, wenn Sie zum Beispiel das Layout einer Seite überprüfen möchten, die ein zufällig ausgewähltes Bild anzeigt, das bei jedem Laden der Seite anders ist. Wenn der Test daher wie unten gezeigt aussieht, wird der Screenshot das Anmeldefeld nicht enthalten.
 

public function notFullPage(VisualTester $I) {
 	$I->wantTo('Test - Startseite vergleichen, nicht die ganze Seite');
 	$I->amOnPage('/');
 	$I->dontSeeVisualChanges("homepage-not-all", "#page", "#block-user-login");
 }

Der letzte Parameter, den wir dem Test hinzufügen können, ist seine Empfindlichkeit gegenüber Änderungen auf der Seite – sein Standardwert wurde bereits in der Konfigurationsdatei festgelegt. Hier können wir den Prozentsatz der Unterschiede auf der Seite erhöhen oder verringern, der während des Testlaufs zu einem Fehler führen wird. Eine solche Änderung könnte nützlich sein, wenn wir die Website auf Änderungen überprüfen möchten, aber eine der Seiten ein kleines variables Element enthält, das Teil eines größeren Ganzen ist, und wir es nicht aus dem Test ausschließen möchten. Ein Beispiel für ein solches Element kann ein Besucherzähler sein – er zeigt jedes Mal einen anderen Wert an, muss aber nicht ausgeschlossen werden. Der unten gezeigte Test gibt nur dann einen Fehler zurück, wenn die Änderungen mehr als 5% der Seite betreffen. 

public function deviation(VisualTester $I) {
 	$I->wantTo('Test - Startseite vergleichen, Abweichung');
 	$I->amOnPage('/');
 	$I->dontSeeVisualChanges("homepage-deviation", "#page", "#block-user-login", 5);
 }

Berichte

Nachdem wir nun mehrere Tests geschrieben haben, um Layoutänderungen auf der Hauptseite zu überprüfen, können wir sie zum ersten Mal ausführen, damit die Referenz-Screenshots erstellt werden. Die Tests sollten genau wie die anderen ausgeführt werden, entweder mit „dcon test“ oder, wenn Sie sich nur für diese spezifische Suite interessieren, verwenden Sie stattdessen „dcon test visual“.

Nachdem die Referenz-Screenshots erstellt wurden, können Sie etwas auf Ihrer Website ändern, um zu sehen, ob Ihre Tests funktionieren. Als Beispiel werde ich den Seitentitel ändern und den Test erneut ausführen. Die ersten drei Tests sind fehlgeschlagen, aber der vierte führte keinen Fehler aus, obwohl der Titel geändert wurde. Dies liegt daran, dass wir die Empfindlichkeit des Tests überschrieben haben – der Prozentsatz der Änderung war zu gering, um einen Fehler zu verursachen.

Natürlich können Sie überprüfen, welche Arten von Tests zu welchen Fehlern im „raport.html“-Datei geführt haben, genau wie bei anderen Tests. Sie enthält Informationen über alle fehlgeschlagenen Tests sowie den prozentualen Unterschied zwischen den verglichenen Seiten.

Bei solchen Tests mag diese Information nicht ausreichen. Deshalb steht Ihnen eine weitere Datei zur Verfügung – vcresult.html – die drei Bilder unter dem Namen jedes fehlgeschlagenen Tests enthält. Das erste Bild zeigt die während des Vergleichs gefundenen Unterschiede und markiert die abweichenden Pixel in Rot. Die folgenden zwei Bilder präsentieren ein erwartetes und aktuelles Ergebnis. 

Projektdaten

Sie können die in diesem Artikel beschriebenen Beispiele aus dem Projekt-Repository laden und den Branch auf visualception ändern.
Projekt-Repository:
https://github.com/DropticaExamples/docker-console-project-example 
Datenbank-Dump:
https://www.dropbox.com/s/r0o3u9gjp3dccd4/database.sql.tar.gz?dl=0 
Projektdaten:
https://www.dropbox.com/s/hl506wciwj60fds/files.tar.gz?dl=0

Zusammenfassung

Ich hoffe, dass dieser Artikel Sie dazu inspiriert hat, mit VisualCeption beim Automatisieren von Tests für Ihre Projekte zu experimentieren. Dieses Modul ist wirklich nützlich, insbesondere wenn Ihr Projekt sehr empfindlich auf alle Änderungen im Seitenlayout reagiert. Schließlich ist bekannt, dass ein Mensch, der die Seite überprüft, einen schlechten Tag haben und eine kleine und scheinbar unbedeutende Änderung übersehen kann. Automatisierte Tests werden jede Änderung bis zum einzelnen Pixel nachverfolgen; jedoch müssen Sie bei der Implementierung dieser Tests daran denken, dass sie erheblich langsamer (im Vergleich zu anderen Testarten) und speicherintensiv sind. 

Wenn Ihnen die Codeception-Tests gefallen haben, behalten Sie unseren Blog im Auge, denn dies ist nicht der letzte Artikel zu diesem Thema.