Visuelle Regressionsprüfungen mit PhantomCSS

Der folgende Beitrag stammt von Jon Bellah, einem Lead Front End Engineer bei 10up. Jon hat uns bezüglich des Themas visuelle Regressionsprüfungen kontaktiert, eine Form der CSS-Tests (d. h. um sicherzustellen, dass man seine Website nicht versehentlich beschädigt). Ich fand den Anwendungsfall besonders interessant: die Neukonstruktion von CSS (Konvertierung in Sass, Aufteilung von Dateien usw.) und die Sicherstellung, dass während dieses Prozesses keine Regressionen auftreten. Hier wird Jon auf all dies sowie auf einige der Herausforderungen visueller Tests (z. B. sich ändernde Inhalte verändern das visuelle Ergebnis) mit cleveren Workarounds eingehen.

Die Übernahme eines Codebases von einem neuen Kunden ist eine der häufigsten und schwierigsten Herausforderungen, denen ich in einer Agentur begegnet bin. In einigen Fällen wechselt ein Kunde zu einer neuen Agentur, weil die vorherige Agentur keine qualitativ hochwertige Arbeit geleistet hat. In fast jedem Fall hat die vorherige Agentur die Dinge nicht so gemacht, wie ich es getan hätte.

Ich befinde mich oft in dieser Situation. Nicht jeder Kunde hat die Notwendigkeit, den Wunsch oder das Budget, von Grund auf neu zu bauen.

Kürzlich hat mein Team den Code eines neuen Kunden übernommen und die Aufgabe erhalten, einige Bereinigungen vorzunehmen und schnell mit der Entwicklung neuer Funktionen zu beginnen. Als wir uns damit beschäftigten, waren wir der Meinung, dass wir ihren Code verbessern und uns den Weg für die Zukunft erleichtern könnten, indem wir ihre Stylesheets auf Sass umstellen.

Obwohl wir die Dateien einfach umbenennen und in ein einziges vorkompiliertes Stylesheet aufnehmen könnten (ohne Bereinigungen vorzunehmen), waren wir der Meinung, dass durch die Neukonstruktion ihrer Stile viel gewonnen werden könnte. Dies würde zwar zunächst etwas mehr kosten, aber wir waren der Meinung, dass es ihnen auf lange Sicht viel Zeit und Geld sparen würde. Vor allem aber würde es uns ermöglichen, mit größerer Sicherheit schneller zu iterieren.

In der Vergangenheit würde ich ein solches Unterfangen als ziemlich hochriskant betrachten. Schließlich steht das C in CSS für "cascading"... die Reihenfolge ist absolut entscheidend. Die Umstrukturierung einer Handvoll von Stylesheets bedeutet, die Reihenfolge zu ändern, in der Dinge erscheinen, was naturgemäß ein hohes Risiko birgt, Dinge kaputt zu machen.

Daher war es immer etwas, das entweder manuell (langsam) getestet wurde oder einfach als zu kostspielig eingestuft wurde.

Dieses Mal haben wir uns jedoch entschieden, eine Suite für visuelle Regressionsprüfungen zu erstellen.

Visuelle Regressionsprüfungen gewinnen seit kurzem an Popularität – und das aus gutem Grund. Im Grunde handelt es sich um eine Reihe von Tests, die Ihre Website durchlaufen, Screenshots von verschiedenen Komponenten erstellen, diese Screenshots mit einer Baseline vergleichen und Sie benachrichtigen, wenn sich etwas ändert.

Das mag für manche Leute kontraintuitiv klingen. Wir ändern CSS, weil wir wollen, dass die Dinge anders aussehen. Warum sollten wir einen Build-Prozess haben, der uns bei jedem Commit einer Änderung an unseren Stylesheets sagt, dass wir etwas kaputt gemacht haben?

Ob Sie die Stile eines Kunden neu strukturieren oder einfach mit einem Team arbeiten, es ist leicht, Änderungen an CSS vorzunehmen, von denen wir glauben, dass sie nur eine Komponente betreffen, nur um später festzustellen, dass wir diese Komponente auf einer völlig anderen Seite kaputt gemacht haben.

Um wirklich zu verstehen, warum visuelle Regressionsprüfungen von Vorteil sein können, halte ich es für hilfreich zu verstehen, was Menschen für diese Aufgabe schlecht macht.

Mensch gegen Maschine

Es stellt sich heraus, dass wir Menschen tatsächlich ziemlich schlecht darin sind, visuelle Veränderungen zu erkennen. Tatsächlich ist unsere Unfähigkeit, Veränderungen wahrzunehmen, zu einem immer stärker untersuchten Bereich physiologischer und psychologischer Phänomene geworden.

Wir haben sogar Spiele daraus gemacht. Erinnern Sie sich an die alten "Finde die Unterschiede"-Bilder?

Es gibt eine Reihe von realen Problemen, die Psychologen gerne verstehen möchten, wie zum Beispiel, wie sich diese Phänomene auf Dinge wie Zeugenaussagen oder Fahrfähigkeiten auswirken; aber in ihrer Forschung finden sich viele Erkenntnisse, die auf unsere Arbeit in der Webentwicklung angewendet werden können.

Ein Phänomen, das meiner Meinung nach besonders relevant für die Konversation ist, ist die Veränderungsblindheit.

Veränderungsblindheit

Die Forschung zum Konzept der Veränderungsblindheit reicht bis in die 1970er Jahre zurück. Im Jahr 1996 führten George McConkie und Christopher Currie, ein Professorenpaar an der University of Illinois Urbana-Champaign, jedoch eine Reihe von Studien durch, die als Auslöser für erhebliches Interesse an den Phänomenen der Veränderungsblindheit gelten.

Veränderungsblindheit ist eine Wahrnehmungsstörung, bei der Veränderungen im visuellen Reiz vorgenommen werden können, ohne dass der Beobachter sie bemerkt. Sie ist nicht mit visuellen Defekten verbunden, sondern rein psychologisch.

In der Studie von McConkie & Currie stellten sie fest, dass in einigen Fällen Veränderungen von bis zu einem Fünftel der Bildfläche regelmäßig unbemerkt bleiben konnten. Dieses Video bietet ein hervorragendes Beispiel dafür, wie viel Veränderung übersehen werden kann, wenn man nicht darauf achtet.

Die Werkzeuge

Wenn es um den Aufbau Ihrer Test-Suite geht, steht eine große Auswahl an Werkzeugen zur Verfügung. Ich empfehle immer, sich umzusehen, Werkzeuge zu vergleichen und herauszufinden, was für Sie am besten funktioniert.

Mit diesem Gedanken habe ich PhantomCSS als mein bevorzugtes Werkzeug für visuelle Regressionsprüfungen gewählt. Ich habe es aus mehreren Gründen gewählt.

Erstens, weil es eine relativ aktive und gesunde Community auf GitHub hat. Wenn es um Open-Source-Software geht, prüfe ich immer gerne und stelle sicher, dass ein Werkzeug oder eine Bibliothek noch aktiv entwickelt wird. Sich auf Abandonware zu verlassen, kann schnell zu Problemen führen.

Der zweite Grund, warum ich PhantomCSS gewählt habe, ist, dass es ein praktisches Grunt-Plugin hat, das es mir ermöglichte, es einfach in meinen bestehenden Workflow zu integrieren.

Im Kern ist PhantomCSS eine Kombination aus drei Schlüsselkomponenten

• PhantomJS oder SlimerJS – Ein Headless-Browser. PhantomJS ist die Headless-Version von WebKit, während Slimer die Gecko-Engine ist, die von Firefox verwendet wird.
• CasperJS – Casper ist ein JavaScript-Navigationsskripting- und Testdienstprogramm. Es ermöglicht uns, eine Reihe von Aktionen zu definieren, die in unserem Headless-Browser stattfinden.
• ResembleJS – Resemble ist eine JavaScript / HTML5-Bibliothek für Bildvergleiche. Sie testet unsere neuen Tests gegen unsere Baseline und benachrichtigt uns über alle Unterschiede zwischen beiden.

Und schließlich werden wir, wie erwähnt, Grunt verwenden, um unsere Tests auszuführen.

Die Implementierung

Nachdem wir nun die Was und Warum kennen, gehen wir die Schritte zur Einrichtung und Implementierung Ihrer Suite für visuelle Regressionsprüfungen durch.

Einrichtung von Grunt

Zuerst müssen wir Grunt einrichten, um unsere Test-Suite auszuführen. Sie sollten also sicherstellen, dass Sie Grunt installiert haben.

Geben Sie im Terminal ein $ cd /pfad/zu/ihrer-website und führen Sie

$ npm install @micahgodbolt/grunt-phantomcss --save-dev

Öffnen Sie die `Gruntfile` Ihres Projekts und laden Sie die PhantomCSS-Aufgabe und definieren Sie die Aufgabe in `grunt.initConfig()`, wie folgt:

grunt.loadNpmTasks('@micahgodbolt/grunt-phantomcss');

grunt.initConfig({
  phantomcss: {
    desktop: {
      options: {
        screenshots: 'baselines/desktop',
        results: 'results/desktop',
        viewportSize: [1280, 800]
      },
      src: [
        'tests/phantomcss/start.js',
        'tests/phantomcss/*-test.js'
      ]
    }
  }
});

Testen verschiedener Breakpoints

Ich verwende gerne Sass MQ zur Verwaltung meiner Breakpoints. Dieser Ansatz bietet den zusätzlichen Vorteil, dass ich eine Liste aller meiner Breakpoints erhalte, die ich einfach zur Einrichtung meiner Tests verwenden kann.

Mit PhantomCSS können Sie die Browserbreite innerhalb Ihrer eigentlichen Testdefinition manipulieren, aber ich ziehe es vor, das aus meinen Tests zu abstrahieren, um meiner Suite für visuelle Tests etwas mehr Flexibilität zu geben. Stattdessen definiere ich es in meiner Grunt-Aufgabe.

Mit grunt-phantomcss können wir eine Reihe von Tests definieren, die bei verschiedenen Breakpoints ausgeführt werden, und als Bonus sie in verschiedenen Ordnern speichern.

Um die Dinge etwas organisierter und semantischer zu halten, benenne ich auch jeden Test-Subtask so, dass er dem entsprechenden Sass MQ Breakpoint entspricht.

Zum Beispiel

grunt.initConfig( {
  pkg: grunt.file.readJSON('package.json'),
  phantomcss: {
    desktop: {
      options: {
        screenshots: 'baselines/desktop',
        results: 'results/desktop',
        viewportSize: [1024, 768]
      },
      src: [
        'tests/phantomcss/start.js',
        'tests/phantomcss/*-test.js'
      ]
    },
    mobile: {
      options: {
        screenshots: 'baselines/mobile',
        results: 'results/mobile',
        viewportSize: [320, 480]
      },
      src: [
        'tests/phantomcss/start.js',
        'test/phantomcss/*-test.js'
      ]
    }
  }
});

Hier führen wir die gleichen Tests durch, aber bei verschiedenen Breakpoints und speichern sie in Unterordnern innerhalb unserer Baselines und Ergebnisse.

Einrichtung Ihrer Test-Suite

In unserer Grunt-Definition sehen wir, dass wir damit beginnen, `tests/phantomcss/start.js` auszuführen. Diese Datei startet Casper (was dann unser Skripting-Tool und unseren Headless-Browser startet) und sollte so aussehen:

phantom.casperTest = true;
casper.start();

Nun, zurück in unserer Grunt-Definition, sehen wir, dass wir dann alle Dateien in unserem Verzeichnis `tests/phantomcss/` ausführen, die auf `-test.js` enden. Grunt wird jede dieser Dateien in alphabetischer Reihenfolge durchlaufen.

Wie Sie Ihre Testdateien organisieren, bleibt Ihnen überlassen. Persönlich erstelle ich gerne eine Testdatei für jede Komponente meiner Website.

Schreiben Ihres ersten Tests

Sobald Ihre `start.js`-Datei eingerichtet ist, ist es Zeit, Ihren ersten Test zu schreiben. Wir nennen diese Datei `header-test.js`.

casper.thenOpen('http://mysite.dev/')

.then(function() {
  phantomcss.screenshot('.site-header', 'site-header');
});

Am Anfang der Datei weisen wir Casper an, die Root-URL zu öffnen. Dann erfassen wir in unserem ersten Test einen Screenshot des gesamten Elements `.site-header`. Der zweite Parameter ist der Name unserer Screenshot-Datei. Ich bevorzuge es, Screenshots nach dem Element oder der Komponente zu benennen, für die sie verantwortlich sind, da dies meine Test-Suite semantischer und leichter mit Teamkollegen zu teilen macht.

In seiner einfachsten Form ist das alles, was Sie für Ihren ersten Test schreiben müssen. Wir können jedoch eine viel robustere Test-Suite aufbauen, die mehr vom tatsächlichen Element, der Seite und den Anwendungszuständen abdeckt.

Skripting von Interaktionen

Casper ermöglicht uns die Automatisierung von Interaktionen, die in unserem Headless-Browser stattfinden. Wenn wir zum Beispiel den Hover-Zustand eines Buttons testen möchten, könnten wir das so schreiben:

casper.then(function() {
  this.mouse.move('.button');
  phantomcss.screenshot('.button');
});

Sie können auch angemeldete und abgemeldete Zustände testen. In unserer `start.js`-Datei können wir eine kleine Funktion schreiben, die das WordPress-Login-Formular ausfüllt, sobald wir unsere Casper-Instanz starten.

casper.start('http://default.wordpress.dev/wp-admin/', function() {
  this.fill('form#loginform', {
    'log': 'admin',
    'pwd': 'password'
  }, true);

  this.click('#wp-submit');

  console.log('Logging in...');
});

Sie werden feststellen, dass wir dies auf `casper.start()` ausführen und nicht innerhalb eines individuellen Tests. Die Einrichtung Ihrer Sitzung auf `casper.start()` in Ihrer `start.js`-Datei macht die Sitzung für andere Dateien in Ihrer Test-Suite verfügbar, da sie immer zuerst ausgeführt wird.

Ich empfehle, die Casper-Dokumentation für weitere Informationen zum Skripting von Interaktionen zu konsultieren.

Ausführen Ihrer Tests

Nachdem wir nun eine grundlegende Test-Suite erstellt haben, ist es Zeit, unsere Tests auszuführen. Geben Sie im Terminal `$ grunt phantomcss` ein.

PhantomCSS wird automatisch die Screenshots aus Ihrer ersten Ausführung als Baselines festlegen, mit denen alle zukünftigen Tests verglichen werden.

Wenn ein Test fehlschlägt, wie der obige, gibt PhantomCSS drei verschiedene Screenshots in Ihrem Ergebnisse-Ordner aus. Es gibt das Original, eine `.diff.png` und eine `.fail.png` aus.

Zum Beispiel haben wir die Schriftgröße von Text auf einer Artikelseite geändert, aber versehentlich die Schriftgröße in einer Archivansicht verringert. PhantomCSS liefert uns diese Diffs zum Vergleichen

Die Herausforderungen

Der Aufbau einer Suite für visuelle Regressionsprüfungen ist sicherlich nicht ohne Herausforderungen. Die beiden größten Herausforderungen, denen ich begegnet bin, sind dynamische Inhalte und die Verteilung von Tests auf ein Team.

Dynamische Inhalte

Die erste und in gewisser Weise schwierigste Herausforderung, der ich begegnet bin, ist, wie genau mit dynamischen Inhalten umgegangen werden soll. Die Test-Suite durchläuft jede dieser Seiten, nimmt Screenshots auf und vergleicht sie. Wenn die Inhalte unterschiedlich sind, wird der Test fehlschlagen.

Wenn Sie mit einem Team arbeiten, testen wahrscheinlich alle gegen ihre eigene lokale Umgebung. Das Testen gegen eine einzige Staging-Umgebung löst das Problem nicht immer, da sich Inhalte dort immer noch ändern können; d. h. eine zufällig sortierte Liste verwandter Beiträge.

Um dieses Problem zu lösen, gibt es zwei Ansätze, die ich bevorzugt habe.

Der erste und mein bevorzugter Ansatz ist die Verwendung von Javascript, um Inhalte innerhalb der Elemente, die Sie testen, durch eine Reihe repräsentativer Demo-Inhalte zu ersetzen.

Da diese Tests nicht auf Ihrem Produktionsserver bereitgestellt werden sollten, müssen Sie sich keine Sorgen über XSS-Schwachstellen machen. Daher verwende ich gerne `.html()` in meinen Tests, um die dynamischen Inhalte durch statische Inhalte aus einem JSON-Objekt zu ersetzen, das ich in mein Code-Repository aufnehme, bevor ich den Screenshot mache.

Der zweite Ansatz ist die Verwendung eines Werkzeugs namens Hologram oder mdcss, die es Ihnen ermöglichen, Kommentare in Ihrem CSS zu verwenden, um automatisch generierte Styleguides zu erstellen. Dieser Ansatz hat mehr Overhead, da er die größte Änderung im Workflow erfordert, bietet aber den zusätzlichen Vorteil, dass er eine hervorragende Dokumentation für Ihre Front-End-Komponenten erstellt.

Verteilung

Die zweite große Herausforderung, der ich bei Regressionstests begegnet bin, ist die Bestimmung des besten Weges, diese Tests auf ein Team von Ingenieuren zu verteilen. Bisher haben wir in unseren Tests unsere Test-URL fest codiert. Dies führt zu Problemen, wenn man mit einem Team arbeitet, bei dem nicht jeder dieselbe URL für seine lokale Umgebung verwendet.

Um dies zu umgehen, haben mein Team und ich unsere `$ grunt test`-Aufgabe so registriert, dass sie einen `--url`-Parameter akzeptiert, der dann lokal in eine Datei gespeichert wird, mithilfe von grunt.log.

// All a variable to be passed, eg. --url=http://test.dev
var localURL = grunt.option( 'url' );

/**
 * Register a custom task to save the local URL, which is then read by the PhantomCSS test file.
 * This file is saved so that "grunt test" can then be run in the future without passing your local URL each time.
 *
 * Note: Make sure test/visual/.local_url is added to your .gitignore
 *
 * Props to Zack Rothauser for this approach.
 */
grunt.registerTask('test', 'Runs PhantomCSS and stores the --url parameter', function() {
  if (localURL) {
    grunt.log.writeln( 'Local URL: ' + localURL );
    grunt.file.write( 'test/visual/.local_url', localURL );
  }

  grunt.task.run(['phantomcss']);
});

Dann, am Anfang Ihrer Testdatei, werden Sie verwenden

var fs = require('fs'), siteURL;

try {
  siteURL = fs.read( 'test/visual/.local_url' );
} catch(err) {
  siteURL = (typeof siteURL === 'undefined') ? 'http://local.wordpress.dev' : siteURL;
}

casper.thenOpen(siteURL + '/path/to/template');

Ihre Suite sucht nun nach der Datei `.local_url`, wenn sie ausgeführt wird. Wenn die Datei jedoch nicht vorhanden ist, wird standardmäßig `http://local.wordpress.dev` verwendet.

Zum Abschluss

Visuelle Regressionsprüfungen können eine Vielzahl von Vorteilen für Ihre Projekte bringen. Schnelle Iteration und kontinuierliche Integration sind zunehmend das Mantra der heutigen Entwickler. Es ist nur sinnvoll, sich ein Sicherheitsnetz aufzubauen.

Eine Suite für visuelle Regressionsprüfungen eignet sich auch hervorragend für die Zusammenarbeit an Open-Source-Projekten. Tatsächlich arbeitet das WordPress-Projekt an einer Pattern Library mit einer begleitenden Suite für Regressionsprüfungen. Diese Test-Suite wird den Grundstein legen, der es dem WordPress-Projekt ermöglicht, seine Pläne zur Wiederherstellung der Übersichtlichkeit seiner Stylesheets voranzutreiben.

Alternativen

PhantomCSS ist nicht das einzige verfügbare Werkzeug, es ist einfach das, das sich für mich, mein Team und unseren Workflow als richtig erwiesen hat. Wenn visuelle Regressionsprüfungen für Sie cool klingen, aber PhantomCSS nicht Ihr Ding ist, oder wenn Sie einfach nur an Alternativen interessiert sind, empfehle ich einen Blick auf

• Selenium
• Wraith