Visuelle Cypress-Tests: stabiler Ablauf

Cypress eignet sich gut, um den Zustand herzustellen, den ein Screenshot zeigen soll. Der Test kann eine Route öffnen, eine instabile API-Antwort abfangen, die Fenstergröße setzen und ein sichtbares Bereitschaftssignal prüfen. Der Screenshot-Befehl hält diesen Zustand fest. Vergleich, Baseline-Speicherung und Freigabe stammen von einem Plugin, einem gehosteten Dienst oder einem getrennten Prüfprozess.

Dieser Leitfaden begleitet eine Prüfung der Preisseite vom lokalen Lauf bis CI. Im Mittelpunkt stehen Entscheidungen gegen falsche Fehler: Welche Daten werden fixiert, wann ist die Seite bereit, wo liegt die Baseline und wer darf eine Änderung freigeben? Außerdem zeigt er, wann RenderLog Cypress bei öffentlichen Seiten ergänzt, die Produkt, Marketing, Betrieb oder Kunden gemeinsam prüfen.

Klären Sie zuerst, wofür Cypress verantwortlich ist

Behalten Sie den Ablauf in Cypress, wenn der Test sich anmelden, Datensätze anlegen, APIs abfangen oder vor der Aufnahme eine Benutzerhandlung ausführen muss. Die Nähe zum Code ist wertvoll: Ein Fehler kann einen Pull Request blockieren und ein Entwickler kann denselben Zustand lokal reproduzieren. Beschreiben Sie vorher Route, Fenstergröße, Benutzer, Sprache, Farbschema, Testdaten und das Element, das die fertige Darstellung bestätigt.

Die Installation eines Screenshot-Plugins erzeugt noch keinen Prüfprozess. Entscheiden Sie, ob Baselines in Git, einem Artefaktspeicher oder einem gehosteten Dashboard liegen. Legen Sie fest, wer ein neues Bild freigibt und wie diese Entscheidung nachvollziehbar bleibt. Ohne klare Zuständigkeit akzeptiert das Team irgendwann beliebige Aktualisierungen oder ignoriert Fehler, obwohl der eigentliche Pixelvergleich technisch korrekt arbeitet.

Nutzen Sie Cypress für Zustände mit Fixtures, Intercepts oder Benutzerabläufen.
Benennen Sie Fenstergröße, Sprache, Thema und Kontostatus im Check.
Wählen Sie Baseline-Speicher und Freigabeverantwortung vor dem ersten Lauf.
Trennen Sie die geplante Überwachung öffentlicher Seiten, wenn sie einen anderen Besitzer hat.

Machen Sie den Seitenzustand vor der Aufnahme reproduzierbar

Eine Preisseite kann Datum, regionale Währung, entfernte Plandaten, Webfonts, einen Chat und wechselnde Referenzen enthalten. Fixieren Sie nur Variablen, die nicht zur Aussage gehören. Fangen Sie die Preisantwort ab, wenn das Layout geprüft wird, setzen Sie Zeitzone und Sprache und deaktivieren Sie Animationen über eine vorgesehene Testoption. Behalten Sie echte Inhalte, wenn gerade deren Veränderung das zu prüfende Risiko ist.

Warten Sie auf eine sichtbare Bedingung statt auf eine feste Pause. Prüfen Sie Überschrift und erwartete Tarifkarten sowie ein bekanntes Bereitschaftssignal der Anwendung. Cypress wiederholt viele Befehle automatisch und ist damit zuverlässiger als eine geschätzte Wartezeit. Eine fehlende Karte sollte zuerst als verständlicher funktionaler Fehler erscheinen, bevor sie zu einem großen, schwer deutbaren Bildunterschied wird.

Fangen Sie instabile Daten nur ab, wenn deren Wert nicht Teil der Prüfung ist.
Setzen Sie Fenstergröße, Zeitzone, Sprache und Farbschema einheitlich.
Verwenden Sie wiederholbare Assertions als Bereitschaftssignal.
Blenden Sie nur den kleinsten irrelevanten dynamischen Bereich aus.

Geben Sie eine geprüfte Baseline frei, nicht das erste Bild

Führen Sie den Test aus und betrachten Sie das vollständige Bild, bevor es zur Baseline wird. Prüfen Sie, ob Fonts geladen sind, das Einwilligungsbanner den erwarteten Zustand hat, Daten vorhanden sind und kein Support-Widget die Handlungsaufforderung verdeckt. Die erste erfolgreiche Aufnahme ist nur ein Kandidat. Nützlich wird sie erst, wenn jemand bestätigt hat, dass sie den gewünschten Produktzustand darstellt.

Bei einer beabsichtigten Designänderung aktualisieren Sie nur betroffene Bilder aus geprüften Ergebnissen. Halten Sie alte und neue Ansicht im Pull Request oder Prüfsystem sichtbar. Ein globaler Snapshot-Update-Befehl ist schnell, kann aber zusammen mit der gewünschten Farbe auch einen verschwundenen Abschnitt freigeben. Kleine, benannte Freigaben verbinden die visuelle Abdeckung mit einer echten Produktentscheidung.

Prüfen Sie jeden ersten Baseline-Kandidaten in voller Größe.
Aktualisieren Sie nur Bilder, die eine beabsichtigte Änderung betrifft.
Bewahren Sie Baseline, aktuelle Aufnahme und Diff für fehlerhafte CI-Läufe auf.
Dokumentieren Sie Prüfer oder Pull Request der Freigabe.

Leiten Sie Vergleichsregeln aus Nachweisen ab

Beginnen Sie mit dem strengsten praktikablen Vergleich in einem festgelegten Browser und Runner. Unterscheiden sich Buchstabenkanten lokal und in CI, gleichen Sie zuerst Fonts, Browserversion und Systemabbild an. Wechselt ein Videobild bei jedem Lauf, ersetzen oder maskieren Sie nur diesen Bereich. Ein hoher globaler Grenzwert kann sonst eine verschobene Schaltfläche an einer anderen Stelle verbergen.

Betrachten Sie den Diff gemeinsam mit beiden Ausgangsbildern. Ein Prozentwert erklärt nicht, ob geänderte Pixel harmlose Kantenglättung oder eine fehlende Kaufaktion zeigen. Nutzen Sie Komponentenaufnahmen, wenn ein kleiner Bereich eine eigene Regel braucht, und Ganzseitenbilder, wenn die Seitenkomposition zählt. Dokumentieren Sie jeden Grenzwert direkt beim Check, damit sein beabsichtigter Toleranzbereich verständlich bleibt.

Fixieren Sie die Laufumgebung, bevor Sie normale Abweichungen messen.
Untersuchen Sie die Position der Änderungen vor einer höheren Toleranz.
Nehmen Sie Komponenten getrennt auf, wenn sie eigene Regeln benötigen.
Behandeln Sie den Pixelanteil als Hinweis, nicht als Produkturteil.

Machen Sie einen fehlerhaften CI-Lauf ohne Wiederholung verständlich

Laden Sie bei jedem Fehler Baseline, aktuelle Aufnahme, Diff und Cypress-Protokolle hoch. Dateinamen sollten Spezifikation, Browser und Fenstergröße enthalten. Ein Prüfer muss eine Produktänderung von einer nie geladenen Seite unterscheiden können, ohne den Job erneut zu starten. Erzeugt die Bibliothek einen HTML-Bericht, bewahren Sie ihn mindestens während des üblichen Prüfzeitraums des Teams auf.

Ordnen Sie Fehler vor jeder Aktualisierung ein. Ein Bereitschafts-Timeout ist ein Test- oder Umgebungsfehler. Eine stabile Seite ohne Tarifkarte ist eine Produktdifferenz. Ein geprüfter neuer Entwurf ist eine erwartete Änderung und darf eine neue Baseline erhalten. Wiederkehrendes Rauschen an Fonts zeigt Umgebungsdrift. Diese Einteilung verhindert, dass Screenshots nur für einen grünen Build akzeptiert werden.

Speichern Sie Baseline, Ergebnis, Diff, Protokolle und Testbericht.
Nehmen Sie Browser und Fenstergröße in Namen oder Metadaten auf.
Trennen Sie Laufabbrüche von abgeschlossenen Vergleichen.
Verlangen Sie eine Prüfung vor der Freigabe erwarteter Änderungen.

Nutzen Sie RenderLog für gemeinsame oder geplante Prüfungen

Repository-Checks passen zu visuellen Assertions, die Code blockieren sollen. Eine öffentliche Preis-, Kunden- oder Kampagnenseite kann einen anderen Rhythmus und Besitzer haben. RenderLog speichert sie als Check, führt sie nach Zeitplan oder API-Aufruf aus und zeigt freigegebene Baseline, aktuelles Ergebnis, Diff und Verlauf in einer Oberfläche, die keinen Zugang zu Cypress CI verlangt.

Duplizieren Sie nicht jeden Cypress-Test. Wählen Sie Seiten, bei denen Freigabesperre und laufende Überwachung wirklich verschiedene Aufgaben sind. Cypress kann einen vorbereiteten Checkout vor dem Merge prüfen, während RenderLog jeden Morgen die produktive Preisseite beobachtet. Verknüpfen Sie beide mit benannten Entscheidungen: Entwickler beheben den Repository-Zustand, Produkt oder Betrieb prüfen die öffentliche Seite.

Behalten Sie Merge-blockierende Anwendungszustände in Cypress.
Verlagern Sie geplante öffentliche Prüfungen in eine gemeinsame Oberfläche.
Duplizieren Sie keinen Zustand ohne getrennten Besitzer und eigene Handlung.
Nutzen Sie die RenderLog-API, wenn ein anderes System den Lauf steuert.

Cypress-Plugin, Screenshot-API oder RenderLog?

Alle drei arbeiten mit Screenshots, lösen aber andere Fragen zu Zustand und Prüfung. Entscheidend ist die Handlung nach einer Differenz, nicht nur die Aufnahmefunktion.

Entscheidung	Cypress-Vergleich	Screenshot-API	RenderLog
Beste Eignung	Code-naher Zustand und Merge-Prüfung	Eine Anwendung benötigt nur ein Bild	Wiederholte Seitenprüfung mit mehreren Beteiligten
Zustandskontrolle	Fixtures, Intercepts, Befehle und Assertions	Anfrageoptionen und Logik des Aufrufers	Gespeicherte Checks, Szenarien, Zeitpläne und API
Baseline-Prüfung	Git, CI-Artefakte oder Plugin-Dienst	Muss der Aufrufer entwickeln	Baseline, Ergebnis, Diff und Verlauf zusammen
Typischer Besitzer	Entwicklung und Codeprüfung	Team der aufrufenden Anwendung	Entwicklung, Produkt, Betrieb, Agentur oder Kunde

Minimaler Ablauf für visuellen Vergleich mit Cypress

Die Beispiele zeigen Zustandskontrolle, Vergleich und CI-Nachweise als getrennte Schritte. Passen Sie Plugin-Befehle an die gewählte Bibliothek an, denn Cypress nimmt Bilder auf, vergleicht sie aber nicht selbst.

cypress.config.ts

import { defineConfig } from "cypress";

export default defineConfig({
  viewportWidth: 1366,
  viewportHeight: 768,
  video: false,
  e2e: {
    baseUrl: "http://127.0.0.1:3000"
  }
});

cypress/e2e/pricing.cy.ts

describe("pricing page", () => {
  it("matches the approved desktop state", () => {
    cy.intercept("GET", "/api/prices", { fixture: "prices.json" }).as("prices");
    cy.visit("/pricing");
    cy.wait("@prices");
    cy.contains("h1", "Pricing").should("be.visible");
    cy.get("[data-testid=plan-grid]").compareSnapshot("pricing-desktop");
  });
});

CI artifact handoff

npx cypress run --browser chrome
# Upload cypress/screenshots/ and the visual plugin's diff output on failure.
# Keep scheduled public-page review in RenderLog when it has a non-code owner.

Primärquellen dieses Leitfadens

Cypress-Befehle und Konfiguration ändern sich. Prüfen Sie aktuelle API-Details in der offiziellen Dokumentation und verwenden Sie diesen Leitfaden für Ablauf, Zuständigkeit und Freigabe.

Fahren Sie mit der passenden Prüfebene fort

Leitfaden zu visuellen Regressionstests

Planen Sie Baselines, Grenzwerte und Verantwortung vor mehr Abdeckung.

Visuelle Tests mit Playwright

Vergleichen Sie den Repository-Ablauf mit Playwright-Assertions.

Visuelle Tests mit Selenium

Ergänzen Sie eine bestehende Selenium-Suite um visuelle Nachweise.

Website-Screenshot-API

Starten Sie sofortige oder gespeicherte Aufnahmen und laden Sie Ergebnisse.

Werkzeuge für visuelle Regression vergleichen

Ordnen Sie Komponenten-, Repository- und gemeinsame Prüflösungen ein.

Überwachen Sie eine produktive Seite außerhalb der Testsuite

Lassen Sie Cypress code-nahe Zustände prüfen und speichern Sie eine öffentliche Preis-, Registrierungs- oder Kampagnenseite in RenderLog, wenn weitere Personen geplante Nachweise und eine verständliche Baseline-Historie brauchen.

RenderLog-Arbeitsbereich erstellen

Visuelle Tests mit Cypress ohne instabile Screenshots