Percy.io – Visuelles Testing-Tool im Detail

1. Allgemeine Einführung in Percy.io

Was ist Percy.io und wofür wird es verwendet?
Percy.io ist ein Cloud-basiertes Tool für visuelles Testing und visuelle Regressionstests in der Softwareentwicklung. Es hilft Entwicklern dabei, Änderungen an der Benutzeroberfläche (UI) automatisch auf unerwünschte visuelle Effekte zu prüfen. Vereinfacht gesagt nimmt Percy Screenshots deiner Anwendung und vergleicht sie pixelgenau mit einem früheren Referenzzustand (Baseline), um Abweichungen hervorzuheben (Best Visual Regression Tools for WordPress – Qode Intractive) (Visual Regression Testing with Percy using Cypress: | by Suraj Patil | nonstopio). Dadurch kann man sofort erkennen, ob ein neues Code-Update z.B. ein Layout verschoben, Farben verändert oder Elemente zum Verschwinden gebracht hat. Visuelles Testing mit Percy schließt eine Lücke, die herkömmliche Unit- und Integrationstests offen lassen: Letztere stellen zwar die korrekte Funktionalität sicher, können aber visuelle Fehler im UI nicht zuverlässig erkennen (Visual testing with Percy: Use cases and benefits | Niteco). Percy wurde entwickelt, um genau diese visuellen Bugs zu finden, bevor sie in Produktion gelangen (A Guide to Visual Testing with Percy — SitePoint) (Visual testing with Percy: Use cases and benefits | Niteco).

Vorteile von Percy für die Softwareentwicklung
Der Einsatz von Percy bringt mehrere Vorteile für Entwickler-Teams:

Integration in bestehende CI/CD-Pipelines
Percy entfaltet seinen vollen Nutzen, wenn es in deine Continuous Integration/Continuous Delivery Pipeline eingebunden ist. Es ist so konzipiert, dass es parallel zu deinem automatisierten Testlauf in CI ausgeführt wird (Integrate Percy with various CI/CD Tools | BrowserStack Docs). Praktisch bedeutet das: Sobald dein CI-System (wie z.B. Jenkins, GitHub Actions, GitLab CI, CircleCI, Travis CI usw.) einen neuen Build anstößt, werden auch die Percy-Visual-Tests ausgeführt. Percy bietet offizielle Integrationen oder Anleitungen für alle gängigen CI-Dienste (Integrate Percy with various CI/CD Tools | BrowserStack Docs).

Die Einrichtung läuft typischerweise folgendermaßen ab:

  1. Percy-Projekt und Token: Zunächst erstellt man auf percy.io ein neues Projekt (über das Percy-Dashboard) und erhält einen eindeutigen Projekt-API-Schlüssel (PERCY_TOKEN). Dieser Token authentifiziert die Schnappschüsse deines Projekts.
  2. Percy in Tests einbinden: In deinem Testcode integrierst du Percy’s SDK oder benutzt den Percy-Agent. Beispielsweise bei Web-UI-Tests mit JavaScript installiert man das npm-Paket @percy/cli (Percy CLI) und ggf. framework-spezifische Bindings (etwa @percy/cypress für Cypress) als Dev-Dependency (Visual Regression Testing with Percy using Cypress: | by Suraj Patil | nonstopio). Dann versieht man die Tests an den relevanten Stellen mit Aufrufen, um Screenshots zu machen. Viele Integrationen bieten einfache Helper – bei Cypress z.B. die Funktion cy.percySnapshot() direkt im Testcode, um einen Screenshot an Percy zu senden (Visual Regression Testing with Percy using Cypress: | by Suraj Patil | nonstopio).
  3. CI-Konfiguration: Im CI-Server wird der Percy-Agent gestartet, wenn die Tests laufen. Meist genügt es, den Befehl zum Testen mit percy exec -- <Test-Befehl> zu prefixen. Ein Beispiel (für Cypress) im Pipeline-Skript: 
    # Beispiel: GitHub Actions Schritt
- name: Run Cypress tests with Percy
  run: npx percy exec -- cypress run
  env:
    PERCY_TOKEN: ${{ secrets.PERCY_TOKEN }}

    Durch percy exec -- ... übernimmt Percy das Starten der Tests und fängt die DOM-Snapshots ab. Wichtig ist, dass der PERCY_TOKEN als Umgebungsvariable im CI-Environment gesetzt ist, damit Percy die Shots dem richtigen Projekt zuordnen kann. Nach Testausführung übermittelt Percy automatisch die aufgenommenen Screenshots an die Cloud (Visual Regression Testing with Percy using Cypress: | by Suraj Patil | nonstopio).

  4. Ergebnisse prüfen: Nach dem CI-Durchlauf kann man im Percy-Dashboard die neuen Snapshots einsehen. Percy erstellt pro CI-Build einen visuellen Build Report. Dort sieht man für jeden Snapshot einen Vergleich Alt vs. Neu, hervorgehobene Differenzen und kann diese entweder als gewollt akzeptieren oder als Problem markieren. Auch der Status in GitHub/GitLab wird entsprechend gesetzt (z.B. erfordert Review, falls ungeprüfte visuelle Änderungen entdeckt wurden). So fügt sich Percy nahtlos in Code-Review-Prozesse ein.

Ein solches Setup bedeutet, dass mit jedem Commit neben Unit- und Integrationstests auch ein visueller Regressionstest durchgeführt wird. Sobald eine Änderung am CSS/Frontend versehentlich etwas kaputt macht, schlägt der visuelle Test Alarm – lange bevor QA-Tester oder Endnutzer den Fehler bemerken. Insbesondere bei komponentenbasierten Frontends oder Design-Systemen ist Percy ein mächtiges Werkzeug, um die UI-Qualität kontinuierlich hochzuhalten.

2. Percy.io in der Praxis: Einsatz in der WordPress-Plugin-Entwicklung

Wie lassen sich die oben genannten Vorteile nun konkret in einem realen Projekt nutzen? In diesem Abschnitt betrachten wir Percy.io aus der Perspektive eines WordPress-Entwicklers. WordPress ist ein verbreitetes CMS, bei dem regelmäßige Updates (Themes, Plugins, Core) immer wieder ungewollte Nebenwirkungen auf das Design haben können (The Top 14 Visual Regression Testing Tools For WordPress). Gerade Plugin-Entwickler müssen sicherstellen, dass ihre Erweiterungen die Darstellung der Website nicht unerwartet verändern – und wenn doch, diese Änderungen bewusst passieren. Hier kann Percy wertvolle Dienste leisten.

Setup und erste Schritte mit Percy.io
Angenommen, du entwickelst ein WordPress-Plugin und möchtest visuelle Tests einführen. Die grundlegenden Schritte für den Einstieg mit Percy sind:

  1. Percy registrieren: Erstelle zunächst ein Konto auf percy.io (falls noch nicht geschehen) und lege ein neues Projekt für dein Plugin an. Wie erwähnt, kannst du dank des Free-Tiers kostenlos loslegen (A Guide to Visual Testing with Percy — SitePoint). Notiere dir den erstellten Projekt-Token.
  2. Testumgebung vorbereiten: Du benötigst eine Umgebung, in der dein WordPress-Plugin läuft und automatisiert aufgerufen werden kann, um Screenshots zu erzeugen. Für visuelle Tests empfiehlt sich ein End-to-End-Testansatz. Du kannst zum Beispiel Cypress einsetzen, um im Browser gegen eine lokale WordPress-Installation zu testen. Installiere Cypress (oder ein ähnliches Tool) sowie die Percy CLI und das entsprechende Percy-SDK. Für Cypress würdest du z.B. aus deinem Projektverzeichnis folgendes ausführen: 
    npm install --save-dev @percy/cli @percy/cypress

    Dadurch stehen dir die Percy-Befehle und -Funktionen im Test zur Verfügung (Visual Regression Testing with Percy using Cypress: | by Suraj Patil | nonstopio).

  3. Percy in Tests integrieren: Als nächstes binde Percy in deine Tests ein. Bei Cypress z.B. fügst du in der Datei cypress/support/e2e.{js,ts} diese Zeile hinzu, um das Percy-Cypress Plugin zu laden: 
    import '@percy/cypress';

    Damit erweitert Cypress seine Kommandos um cy.percySnapshot(). Jetzt kannst du in deinen Tests Snapshots aufnehmen. Angenommen, dein Plugin fügt dem Frontend eine spezielle Seite hinzu, könntest du einen Test schreiben:

    describe('Visual Test for MyPlugin', () => {
  it('Seite sieht korrekt aus', () => {
    cy.visit('/my-plugin-page');        // Plugin-Seite aufrufen
    cy.get('h1').should('contain', 'My Plugin');  // Beispielhafte Prüfung
    cy.percySnapshot('MyPlugin Seite'); // Screenshot für Percy aufnehmen
  });
});

    Im obigen Beispiel navigiert der Test auf eine Seite, die vom Plugin generiert wird, prüft einen erwarteten Inhalt und erstellt dann einen Percy-Snapshot mit dem Namen „MyPlugin Seite“. Dieser Snapshot wird an Percy gesendet und mit dem Baseline-Bild verglichen, sobald der Test in der CI läuft.

  4. Tests via Percy ausführen: Führ die Tests nun lokal oder in CI via Percy aus. Lokal könntest du den Befehl direkt verwenden, z.B.: 
    export PERCY_TOKEN=<DEIN_TOKEN>
npx percy exec -- cypress run

    Dadurch startet Percy einen lokalen Snapshot-Server, führt die Cypress-Tests aus und lädt anschließend die Screenshots hoch (Visual Regression Testing with Percy using Cypress: | by Suraj Patil | nonstopio). In der CI-Pipeline würde man analog vorgehen (dort setzt man PERCY_TOKEN als geschützte Variable und nutzt ebenfalls percy exec -- ...). Sobald der Build durch ist, findest du online im Percy-Dashboard die Resultate.

Integration in ein bestehendes WordPress-Plugin
Stell dir vor, du hast bereits ein WordPress-Plugin in Entwicklung, das bestimmte UI-Komponenten im Frontend oder Backend darstellt – beispielsweise ein Formular, ein Widget oder eine Admin-Seite. Wie integrierst du Percy nun in dieses vorhandene Projekt? Im Grunde ändert sich an der Herangehensweise nichts: Du ergänzt zu deinem Plugin-Projekt eine Test-Suite, die das WordPress-System mit aktiviertem Plugin anstartet und die relevanten Oberflächen rendert, um Screenshots aufzunehmen.

Ein pragmatischer Weg für WP-Plugins ist die Verwendung von End-to-End-Tests mit einer echten Browserinstanz. Du könntest etwa eine WordPress-Installation in Docker oder auf localhost haben, auf der dein Plugin aktiv ist. Mit Cypress (oder einem ähnlichen E2E-Framework) steuerst du den Browser: öffne die Seite X, klicke auf Button Y, etc., und an definierten Punkten machst du einen Snapshot. Für das Backend (WP-Admin) müsstest du vorher einen Login-Skript ausführen, um ins Dashboard zu gelangen.

Tipp: Um Cypress in einer WP-Umgebung zu nutzen, gibt es Hilfsbibliotheken und Plugins. Du kannst z.B. WP spezifische Commands nutzen (Login via WP REST API Token) oder einen bestehenden Test-Bootstrap. Das Setup mag ein wenig Aufwand sein, aber lohnt sich für robuste Tests. Alternativ lassen sich visuelle Tests auch mit PHP-basierten Tools (Codeception + WP-Browser) schreiben, die Percy ebenfalls ansprechen können.

Nehmen wir an, dein Plugin fügt dem Frontend ein bestimmtes Markup hinzu (z.B. einen Shortcode [myplugin], der eine Galerie rendert). Dann könntest du testweise eine WP-Seite erstellen, auf der dieser Shortcode eingebunden ist, und mit Percy prüfen, dass die Galerie immer gleich aussieht. Genauso im Backend: Falls dein Plugin ein eigenes Einstellungs-Menü hat, kannst du die Admin-Seite laden und als Snapshot festhalten. Percy zeigt dir dann bei jedem Testlauf an, ob sich z.B. Styles oder Icons geändert haben.

Automatisierte visuelle Tests für UI-Komponenten
Durch die Integration von Percy in die Entwicklung deines WordPress-Plugins erhältst du eine automatisierte visuelle Abnahme für alle wichtigen UI-Komponenten deines Plugins. Bei jeder Änderung am Plugin-Code (sei es CSS-Anpassung, Update der JavaScript-Bibliothek oder Ähnliches) laufen die Percy-Tests und bewahren dich davor, unbeabsichtigte Designänderungen zu übersehen.

Ein konkretes Beispiel: Angenommen, dein Plugin enthält ein benutzerdefiniertes Formular im Frontend. Mit Percy könntest du folgende Zustände als Snapshots abdecken:

  • Baseline-Zustand: Formular wird korrekt angezeigt (z.B. mit Standardwerten, ohne Fehlermeldungen).
  • Interaktionszustand: Ein Benutzer hat fehlerhafte Eingaben gemacht, und Validierungsmeldungen erscheinen rot unter den Feldern. Dieser Zustand wird ebenfalls als Screenshot festgehalten.

Wenn nun ein Entwickler am CSS des Formulars etwas ändert, könnten plötzlich die Fehlermeldungen nicht mehr rot, sondern z.B. schwarz erscheinen (Bug!). Percy würde beim nächsten Testlauf den Unterschied markieren – roter Text vs. schwarzer Text – und der Entwickler sieht sofort im visuellen Diff, dass hier etwas nicht stimmt. Ohne visuellen Test wäre solch eine Regression eventuell erst live oder im manuellen Test aufgefallen.

Gerade WordPress-Updates sind eine Gefahr: Aktualisiert der Nutzer deine Plugin-Version oder es ändert sich etwas im WP-Core/CSS, kann die Darstellung leiden. Percy fängt solche Regressionen nach Updates zuverlässig ab. Ein Praxisbericht zeigt, dass WordPress-Updates oder neue Plugin-Versionen oft UI-Probleme verursachen, die durch visuelle Tests direkt ans Licht kommen (The Top 14 Visual Regression Testing Tools For WordPress). Als Entwickler kannst du dann proaktiv reagieren, bevor Benutzer den Fehler bemerken.

Im nächsten Abschnitt kombinieren wir dieses Wissen über Percy mit einem spannenden Anwendungsfall: Wir entwickeln ein kleines WordPress-Plugin, das KI-Technologie einsetzt, und nutzen Percy, um dessen UI zu testen.

3. Technische Umsetzung: Entwicklung eines WordPress-Plugins mit KI-Unterstützung

In diesem Abschnitt gehen wir Schritt für Schritt durch die Erstellung eines WordPress-Plugins, das mithilfe von KI (Künstlicher Intelligenz) Content-Vorschläge erzeugt. Dabei integrieren wir Percy.io, um die Benutzeroberfläche dieses Plugins visuell zu testen. Das Beispiel richtet sich an Entwickler, soll aber auch für Einsteiger verständlich bleiben – wir erläutern also die wichtigsten Konzepte und zeigen Code-Beispiele.

Plugin-Idee:
Unser Plugin soll Website-Betreibern vorschlagen können, wie sie bestehende Seiteninhalte erweitern oder verbessern können. Konkret könnte ein Anwendungsfall so aussehen: Ein Redakteur öffnet eine Seite im WordPress-Editor und klickt auf einen Button „KI-Vorschlag generieren“. Daraufhin analysiert unser Plugin den bisherigen Seiteninhalt und ruft eine KI (z.B. die OpenAI API) auf, um einen Vorschlag für einen zusätzlichen Absatz oder neue Sektion zu erhalten. Dieser generierte Text wird dem Redakteur angezeigt, der ihn prüfen und per Klick in den Inhalt übernehmen kann. So eine Funktion kann beim Brainstorming helfen oder Schreibblockaden lösen – und spart Zeit.

Diese Idee ist gar nicht so weit hergeholt: Es gibt bereits Plugins, die KI nutzen, z.B. SEO-Plugins wie AIOSEO, welches per OpenAI API Meta-Beschreibungen vorschlägt (14 Best Ways to Use OpenAI on Your WordPress Website (2025)). Wir bauen nun eine vereinfachte eigene Lösung.

Schritt 1: Grundstruktur des Plugins
Ein WordPress-Plugin besteht mindestens aus einer PHP-Hauptdatei mit Header-Kommentar. Für unser Plugin legen wir im Ordner wp-content/plugins/ eine neue Datei an, z.B. content-ai-suggester.php. Dort schreiben wir:

<?php
/**
 * Plugin Name: Content AI Suggester
 * Description: Bietet KI-gestützte Vorschläge zur Erweiterung von Seiteninhalten.
 * Version: 1.0
 * Author: Dein Name
 */

 // Code wird hier eingefügt...

Mit diesem Header kann WordPress das Plugin erkennen. Nach dem Kommentar fügen wir den eigentlichen Code ein. Wir planen zwei Kernfunktionen:

  1. Admin-Menü und Oberfläche erstellen: Eine Einstellungsseite im Dashboard, auf der der Admin einen KI-Vorschlag anfordern kann.
  2. KI-Aufruf implementieren: Die Logik, um den aktuellen Seiteninhalt an eine KI-API zu senden und die Antwort zu verarbeiten.

Beginnen wir mit dem Admin-Interface.

Schritt 2: Admin-Oberfläche einbinden
Wir möchten im WordPress-Admin-Menü einen neuen Eintrag (z.B. unter „Werkzeuge“ oder als eigenes Menü) hinzufügen, über den man zu unserer Plugin-Seite gelangt. Dort soll ein einfaches Formular sein: ein Textfeld für den vorhandenen Inhalt (bzw. Auswahl einer Seite) und ein „Vorschlag generieren“ Button. Nach Absenden des Formulars ruft das Plugin die KI-API und zeigt den erhaltenen Vorschlag darunter an.

Für den Menüeintrag nutzen wir die WP-API-Funktion add_menu_page(). Diese registrieren wir am besten bei der Admin-Initialisierung:

// Im Hauptplugin-Code, z.B. content-ai-suggester.php
add_action('admin_menu', function() {
    add_menu_page(
        'Content AI Suggestions',      // Seiten-Titel
        'Content AI',                  // Menü-Titel
        'manage_options',             // erforderliche Capability
        'content-ai-suggester',       // Menü-Slug (Seitenkennung)
        'render_content_ai_page',     // Callback zum Anzeigen der Seite
        'dashicons-lightbulb',        // Icon (Dashicon)
        100                           // Position im Menü
    );
});

Die obige Registrierung fügt dem WP-Admin ein neues Hauptmenü Content AI mit Glühbirnen-Icon hinzu. Beim Klick ruft WP die Funktion render_content_ai_page() auf, die wir nun definieren:

function render_content_ai_page() {
    echo '<div class="wrap"><h1>Content AI Vorschläge</h1>';
    // Wurde das Formular abgeschickt?
    if (isset($_POST['base_content'])) {
        $baseText = sanitize_textarea_field($_POST['base_content']);
        $suggestion = get_content_suggestion($baseText);
        if (!empty($suggestion)) {
            echo '<h2>Vorschlag der KI:</h2>';
            echo '<p><em>' . esc_html($suggestion) . '</em></p>';
        } else {
            echo '<p><em>Keine Antwort von der KI erhalten.</em></p>';
        }
    }
    // Formular anzeigen
    echo '<form method="post" style="max-width:600px;">';
    echo '<p><label for="base_content">Seiteninhalt eingeben:</label></p>';
    echo '<textarea name="base_content" id="base_content" rows="5" class="large-text" placeholder="Gib hier einen bestehenden Absatz oder Inhalt ein..."></textarea>';
    echo '<p><button type="submit" class="button button-primary">KI-Vorschlag generieren</button></p>';
    echo '</form></div>';
}

Was passiert hier? Wir erzeugen die HTML-Ausgabe für die Plugin-Seite. Wenn das Formular schon abgeschickt wurde ($_POST['base_content'] ist gesetzt), nehmen wir den Inhalt, säubern ihn mit WordPress-Funktionen (gegen XSS) und rufen unsere KI-Funktion get_content_suggestion() auf (die wir gleich schreiben). Deren Antwort wird dann als kursiver Text unter „Vorschlag der KI:“ ausgegeben. Danach wird immer ein Formular dargestellt, in dem der Admin einen Text eingeben kann – als Ausgangsbasis für die KI.

Schritt 3: Anbindung der KI-API (OpenAI)
Der Kern unseres Plugins ist die Kommunikation mit der KI. In diesem Beispiel verwenden wir die OpenAI API (z.B. GPT-3 bzw. GPT-4 Modell), da diese leistungsfähig Text generieren kann. Wir brauchen einen API-Schlüssel von OpenAI – diesen würde man in der Praxis in den Plugin-Einstellungen hinterlegen oder via Konstante konfigurieren (aus Sicherheitsgründen nicht hardcoden). Hier im Beispiel setzen wir ihn als Platzhalter.

Die WordPress-HTTP-API bietet die Funktion wp_remote_post() an, mit der wir HTTP-Anfragen senden können. Über diese Funktion können wir die REST-API von OpenAI aufrufen (How to use ChatGPT API in WordPress using the wp_remote_get function? – Mohammad Tajim). OpenAI erwartet bei Text-Komplettierungen (Stand GPT-3) einen POST-Request an https://api.openai.com/v1/completions oder bei neueren Modellen ggf. .../v1/chat/completions, jeweils mit bestimmten Parametern im JSON-Body (Prompt, Modell, Temperature etc.), sowie unseren API-Schlüssel im Authorization-Header.

Wir implementieren nun get_content_suggestion($text) im Plugin:

function get_content_suggestion($text) {
    $api_key = 'DEIN_OPENAI_API_KEY';  // TODO: In Produktion sicher speichern!
    $api_url = 'https://api.openai.com/v1/engines/text-davinci-003/completions';

    // Anfrage-Daten vorbereiten
    $data = array(
        'prompt'      => "Erweitere folgenden Inhalt:\n\"$text\"\n\nVorschlag:",
        'max_tokens'  => 150,
        'temperature' => 0.7,
    );
    $args = array(
        'headers' => array(
            'Content-Type'  => 'application/json',
            'Authorization' => 'Bearer ' . $api_key,
        ),
        'body'    => json_encode($data),
        'timeout' => 15,
    );

    // API-Request absenden
    $response = wp_remote_post($api_url, $args);
    if (is_wp_error($response)) {
        error_log('ContentAI Plugin – API Fehler: ' . $response->get_error_message());
        return '';
    }
    $body = wp_remote_retrieve_body($response);
    $result = json_decode($body, true);
    if (isset($result['choices'][0]['text'])) {
        // Trim, um etwaige neue Zeilen am Anfang/Ende zu entfernen
        return trim($result['choices'][0]['text']);
    }
    return '';
}

Schauen wir uns diesen Code an: Wir nutzen text-davinci-003 als Engine (GPT-3 Modell) über die Completions-API. Der Prompt, den wir senden, enthält unseren übergebenen $text (den bestehenden Seiteninhalt) und bittet die KI, diesen Inhalt zu erweitern („Erweitere folgenden Inhalt…“). Wir beschränken die Antwort auf 150 Tokens und wählen eine Temperature von 0.7 (d.h. die KI-Antwort darf leicht kreativ/variierend sein). In $args setzen wir die nötigen Header: Content-Type JSON und unseren API-Key als Bearer-Token (How to use ChatGPT API in WordPress using the wp_remote_get function? – Mohammad Tajim). Dann führen wir den POST-Request aus.

Die Antwort von OpenAI wird als JSON zurückkommen. Typischerweise enthält sie ein Array 'choices', wobei choices[0]['text'] den generierten Text enthält (bei Completions-API). Wir dekodieren das JSON mit json_decode und extrahieren den Text. Falls die API einen Fehler liefert oder kein Text vorhanden ist, geben wir einfach einen leeren String zurück. (Hinweis: Bei der neueren Chat-Completions-API würde die Struktur etwas anders aussehen, aber das Prinzip bleibt ähnlich.)

Mit dieser Funktion haben wir die KI-Integration abgeschlossen. Wichtig: In einer echten Anwendung sollte der API-Schlüssel nicht im Quellcode stehen. Man würde ihn über die Plugin-Einstellungen eingeben und per get_option() laden, oder z.B. in der wp-config.php definieren und ins Plugin übernehmen. Außerdem kann man die Kommunikation absichern (z.B. OpenAI-HTTP-Fehler behandeln, Rate Limits beachten etc.), doch für unser einfaches Beispiel belassen wir es hierbei.

Schritt 4: Plugin testen und nutzen
Wenn wir das Plugin nun in WordPress aktivieren, erscheint im Dashboard-Menü der Eintrag „Content AI“. Dort können wir einen Beispieltext eingeben (z.B. einen Absatz aus einer bestehenden Seite) und auf „KI-Vorschlag generieren“ klicken. Das Plugin sendet die Anfrage an OpenAI und zeigt nach wenigen Sekunden den erhaltenen Vorschlag an. Der Redakteur könnte diesen dann manuell kopieren und in seinen Beitrag übernehmen. (Für eine Komplettlösung könnte man einen „Übernehmen“-Button ergänzen, der den Text direkt in einen Beitrag einfügt, aber das lassen wir hier weg.)

Bis hierhin haben wir ein funktionierendes Plugin, das KI-gestützte Content-Vorschläge liefert. Nun kommen wir zum Qualitätssicherungs-Aspekt: automatische visuelle Tests mit Percy.

Automatische visuelle Tests mit Percy.io
Warum ist Percy für unser Plugin hilfreich? Stellen wir uns vor, wir entwickeln das Plugin weiter, ändern CSS-Stile der Admin-Seite, fügen neue Elemente hinzu etc. Wir möchten sicher sein, dass diese Änderungen die Benutzeroberfläche nicht unbeabsichtigt zerstören. Außerdem könnten Änderungen im WordPress-Admin-Design (etwa durch ein WP-Update) Einfluss auf unsere Plugin-Seite haben. Mit Percy können wir diese Oberflächen automatisiert prüfen.

Was würden wir konkret testen? Ein paar Ideen:

  • Darstellung der Admin-Seite ohne Vorschlag: Direkt nach Aufruf der Seite „Content AI Vorschläge“ – ist das Formular korrekt formatiert, stimmen Abstände, ist der Titel sichtbar?
  • Darstellung nach Abruf eines Vorschlags: Nachdem der Admin einen Text eingegeben und einen KI-Vorschlag erhalten hat – erscheint der Vorschlagstext korrekt formatiert (kursiv, unter der Überschrift), bleibt das Formular sichtbar, sind keine Elemente verrutscht?

Um das zu testen, können wir z.B. mit Cypress zwei Szenarien automatisieren. Pseudocode für Cypress könnte so aussehen (Annahme: wir haben bereits einen Weg, uns im Admin anzumelden, z.B. via WP REST oder direkt per Login-Form):

// Beispielhafter Cypress-Testablauf (Pseudocode)
it('Content AI Admin-Seite visuell testen', () => {
  cy.login('adminuser', 'password');                    // Admin-Login durchführen
  cy.visit('/wp-admin/admin.php?page=content-ai-suggester');  // Plugin-Seite aufrufen
  cy.percySnapshot('Content AI Page - initial');        // Anfangszustand aufnehmen

  // Nun füllen wir das Formular aus und lösen die KI-Abfrage aus.
  cy.get('textarea#base_content').type('Dies ist ein Testabsatz.');
  cy.contains('KI-Vorschlag generieren').click();
  // Warten bis die Antwort geladen und angezeigt wurde:
  cy.get('h2').should('contain', 'Vorschlag der KI:');
  cy.percySnapshot('Content AI Page - with suggestion'); // Zustand nach KI-Antwort
});

Dieser Test würde zwei Snapshots erzeugen: einen vom leeren Formular und einen nach Anzeige des KI-Textes. Im Percy-Dashboard könnten wir nun pixelgenau verfolgen, ob sich zwischen verschiedenen Plugin-Versionen oder WP-Versionen etwas ändert (z.B. Verschiebungen durch andere Styles). Besonders nützlich ist es, diesen Test in der CI auszuführen, z.B. bei jedem GitHub Pull-Request. So sieht ein Reviewer sofort die Auswirkungen der Codeänderung auf die UI des Plugins.

Hinweis: Da KI-generierte Inhalte sich bei jedem Aufruf ändern können, bekommt man theoretisch bei jeder Ausführung einen anderen Vorschlagstext – Percy würde dies als Unterschied markieren (weil der Textinhalt anders ist). Um vergleichbare Snapshots zu erhalten, kann man in Testumgebungen den API-Call mocken oder einen festen Response vorgeben. Beispielsweise könnte man get_content_suggestion() so umbauen, dass es im Testmodus (erkannbar z.B. an einer Konstante) immer einen statischen Dummy-Text zurückgibt. Alternativ könnte man den Percy-Snapshot so konfigurieren, dass dynamische Inhalte ignoriert werden (Percy bietet dafür Masking- und Ignore-Regions in manchen SDKs). Für unser Verständnisbeispiel gehen wir nicht tiefer darauf ein – in echten Projekten ist das jedoch ein wichtiges Detail, um Flakiness zu vermeiden.

Mit diesen Tests erreichen wir, dass unser KI-Plugin nicht nur funktional geprüft ist, sondern auch optisch. Kombiniert man Percy mit herkömmlichen Unit-/Integrationstests (für die PHP-Logik, API-Aufruf etc.), erhält man eine sehr umfassende Testabdeckung.

Zusammenspiel von KI und visuellem Testing: Interessanterweise profitieren wir hier doppelt von Automatisierung: Auf der einen Seite automatisiert die KI Content-Vorschläge, auf der anderen Seite automatisiert Percy die visuelle Qualitätskontrolle. Moderne Entwicklungsprojekte kombinieren solche Tools, um sowohl Produktivität zu steigern (schneller Inhalte generieren, Features entwickeln) als auch Qualität zu sichern (Fehler früh abfangen). Im nächsten Abschnitt fassen wir die Erkenntnisse zusammen.

4. Zusammenfassung und Fazit

In diesem Blog-Beitrag haben wir Percy.io als leistungsfähiges Werkzeug für visuelles Testing kennengelernt und praxisnah erläutert, wie man es in der Entwicklung – speziell bei WordPress-Plugins – einsetzt. Zum Abschluss hier die wichtigsten Punkte und Erkenntnisse:

  • Visuelles Testing mit Percy erhöht die Qualität und Stabilität der Benutzeroberfläche von Webanwendungen. Es ergänzt klassische Tests, indem es sicherstellt, dass ein Update keine unbeabsichtigten visuellen Änderungen mit sich bringt (Visual testing with Percy: Use cases and benefits | Niteco). Die automatischen Screenshot-Vergleiche machen selbst kleinste UI-Differenzen sichtbar, sodass Entwickler mit jedem Commit überprüfen können, ob die Anwendung optisch korrekt bleibt (Visual testing with Percy: Use cases and benefits | Niteco).
  • Einfache Integration in Workflows: Percy lässt sich nahtlos in bestehende Entwicklungs- und Deployment-Workflows integrieren. Für Entwickler bedeutet das geringen Mehraufwand: Hat man einmal die Tests und das Percy-Projekt eingerichtet, laufen die visuellen Prüfungen kontinuierlich mit. Die Unterstützung aller gängigen CI-Systeme und Frameworks macht die Einrichtung unkompliziert (Integrate Percy with various CI/CD Tools | BrowserStack Docs) (Integrate Percy with various CI/CD Tools | BrowserStack Docs). Gerade für Teams, die Pull-Requests verwenden, ist Percy ein Segen – man bekommt zu jedem PR einen visuellen Diff und kann Änderungen im Design direkt im Code-Review ansprechen.
  • Effizienzsteigerung: Durch Percy spart man manuelle Abnahmerunden im Browser. Die Zeit, in der Entwickler oder Tester jeden Screen nach UI-Änderungen absuchen mussten, wird drastisch reduziert. Stattdessen konzentriert man sich auf die von Percy gemeldeten Unterschiede. Das beschleunigt Releases und gibt dem Team mehr Vertrauen, auch große Refactorings durchzuführen, denn visuelle Fehler werden zuverlässig aufgezeigt (Visual Regression Testing with Percy using Cypress: | by Suraj Patil | nonstopio).
  • Wert für WordPress-Entwickler: Im Kontext von WordPress (wo Updates häufig und das Ökosystem groß ist) bietet Percy einen besonderen Mehrwert. Änderungen durch Core-Updates oder Plugin-Interaktionen, die das Frontend beeinflussen, lassen sich mit visuellen Tests abfangen (The Top 14 Visual Regression Testing Tools For WordPress). Plugin-Entwickler können so sicherstellen, dass ihre Features auf verschiedenen Seiten und Themes konsistent dargestellt werden. Und im Teamwork an einem Plugin ermöglicht Percy, Design-Änderungen transparent zu machen – jeder im Team sieht sofort, wie sich ein Commit XY visuell auswirkt.
  • KI-gestützter Content & visuelles Testing – eine gewinnbringende Kombination: Unser Beispiel-Plugin hat gezeigt, wie man KI-Funktionen (hier: Content-Vorschläge via OpenAI) relativ einfach in WordPress integrieren kann. Solche KI-Features bieten Mehrwert für die Nutzer, aber man muss sie natürlich gut implementieren und testen. Percy stellt sicher, dass die Integration der KI ins UI reibungslos verläuft – z.B. dass die Ausgabe der KI-Vorschläge ordentlich formatiert ist und keine bestehenden Elemente überdeckt. So verbindet man innovativen Funktionsumfang (durch KI) mit hoher Qualitätskontrolle (durch visuelles Testing). Das Ergebnis sind zufriedene Entwickler und Nutzer: Entwickler können schneller neue Ideen (mit Hilfe von KI) umsetzen, ohne Angst vor versteckten UI-Bugs haben zu müssen, und Nutzer erhalten ein rundum stimmiges, fehlerfreies Erlebnis.

Fazit: Percy.io hat sich als wertvolles Werkzeug erwiesen, um die Frontend-Qualität in modernen Entwicklungsprojekten sicherzustellen. Speziell Entwickler, die mit visuell ausgerichteten Systemen wie WordPress arbeiten, profitieren von der automatisierten Screenshot-Überprüfung. In Kombination mit innovativen Ansätzen – wie KI-gestütztem Content – stellt Percy sicher, dass neue Features nicht auf Kosten der Stabilität gehen. Für Einsteiger mag das Einrichten von Percy zunächst wie zusätzlicher Aufwand wirken, doch die Investition zahlt sich schnell aus: Weniger Fehler nach Deployments, schnellere Feedback-Loops und letztlich ein produktiveres Entwicklungsteam. Kurz gesagt: KI bringt neue Möglichkeiten, Percy hält die Qualität – zusammen ergeben sie effizientere Workflows und bessere Software.

Von Published On: 23.2.2025Kategorien: KI, WebdevelopmentSchlagwörter: , , ,