Cypress Visual Testing: Der vollstaendige Leitfaden zum Hinzufuegen von Visual Testing
Visual Testing (oder visuelles Testen) ist eine automatisierte Pruefmethode, die Screenshots einer Weboberflaeche mit Referenzbildern vergleicht, um jede grafische Regression zu erkennen — einen verschobenen Button, eine geaenderte Schrift, ein Element, das ein anderes ueberlappt.
Cypress ist ein grossartiges Tool. Wir schaetzen es fuer seine Geschwindigkeit, seine intuitive API, seine riesige Community. Aber seien wir von Anfang an ehrlich: Cypress macht kein natives Visual Testing. Im Gegensatz zu Playwright, das toHaveScreenshot() direkt integriert, zwingt Cypress Sie, mit Drittanbieter-Plugins zu basteln, um auch nur den einfachsten Screenshot-Vergleich zu erhalten.
Und das ist ein ernsthafteres Problem, als es scheint.
Dieser Leitfaden behandelt die bestehenden Ansaetze zum Hinzufuegen von Visual Testing zu Cypress, ihre realen Grenzen und warum ein radikal anderer Ansatz Ihre Aufmerksamkeit verdient.
Warum Cypress kein integriertes Visual Testing hat
Das ist die Frage, die niemand laut genug stellt. Playwright hat es getan. Warum nicht Cypress?
Die offizielle Antwort ist diplomatisch: Cypress konzentriert sich auf funktionales Testing. Die ehrliche Antwort ist nuancierter. Visual Testing ist ein komplexes Problem — Baseline-Management, Toleranz fuer Rendering-Unterschiede, Antialiasing, Animationen — und Cypress hat sich entschieden, das Plugin-Oekosystem damit zu beauftragen.
Das Ergebnis? Eine Fragmentierung. Jedes Plugin macht die Dinge auf seine eigene Weise, mit eigenen Konventionen, eigenen Bugs und eigenem Risiko der Einstellung. Sie waehlen nicht eine offizielle und unterstuetzte Loesung. Sie setzen auf ein Open-Source-Projekt, das von einer Handvoll Contributor gepflegt wird — oder auf einen kostenpflichtigen Cloud-Dienst.
Fuer Teams, die ihre gesamte Testsuite auf Cypress aufgebaut haben, ist das ein echtes Dilemma. Nur wegen Visual Testing zu Playwright migrieren ist unrealistisch. Ein fragiles Plugin hinzufuegen auch nicht. Schauen wir, was es gibt.
Ansatz 1: cypress-image-snapshot
Das bekannteste Plugin im Oekosystem. Es basiert auf jest-image-snapshot (selbst basierend auf pixelmatch) fuer den Pixel-fuer-Pixel-Vergleich von Screenshots.
Wie es funktioniert
Die Installation erfordert einige Eingriffe in der Cypress-Konfiguration — nichts Unueberwindliches, aber genug Dateien zum Anfassen, dass sich leicht ein Fehler einschleichen kann. Wenn Sie die genauen Befehle wollen, bitten Sie Ihren bevorzugten KI-Assistenten, die Konfiguration zu generieren: Er liebt das und langweilt sich sonst zwischen zwei Haikus ueber Machine Learning.
Einmal eingerichtet ist das Prinzip einfach: Sie fuegen einen benutzerdefinierten Befehl zu Ihren Tests hinzu, der den Bildschirm erfasst und mit einem im Repository gespeicherten Referenzbild vergleicht. Die erste Ausfuehrung erstellt die Baseline. Die folgenden erkennen Abweichungen.
Die Grenzen, die man Ihnen nicht sagt
Das Wartungsproblem. Dieses Plugin hat laengere Inaktivitaetsperioden erlebt. Zum Zeitpunkt, an dem Sie dies lesen, pruefen Sie das Datum des letzten Commits auf GitHub. Wenn es mehr als sechs Monate zurueckliegt, sollten Sie sich Fragen stellen.
Die False Positives. Der Pixel-fuer-Pixel-Vergleich ist brutal. Ein leicht anderes Font-Rendering zwischen Ihrem Rechner und der CI? False Positive. Ein Antialiasing, das je nach GPU variiert? False Positive. Sie verbringen mehr Zeit mit dem Kalibrieren der Toleranzschwellen als mit dem Schreiben von Tests.
Keine Review-Oberflaeche. Wenn ein Test fehlschlaegt, erhalten Sie ein Diff-Bild in einem Ordner. Kein Dashboard, kein Genehmigungsworkflow. Sie oeffnen das Bild in Ihrem Dateimanager und kneifen die Augen zusammen, um den Unterschied zu finden. Das ist handwerklich.
Baselines in Git. Hunderte PNG-Bilder in Ihrem Repository. Merge-Konflikte bei Binaerdateien sind ein Albtraum. Die Git-History blaeeht sich auf. Manche Teams enden bei Git LFS, was eine weitere Komplexitaetsebene hinzufuegt.
Ansatz 2: Percy (BrowserStack)
Percy ist ein Cloud-basierter Visual Testing Dienst, der sich ueber ein SDK in Cypress integriert. Der Ansatz ist grundlegend anders: Statt lokal zu vergleichen, sendet Percy das DOM und die Assets an seine Server, rendert die Seite in echten Browsern und vergleicht die Ergebnisse in einem Web-Dashboard.
Wie es funktioniert
Sie installieren das Percy-SDK fuer Cypress, fuegen einen Aufruf in Ihren Tests hinzu, um einen Snapshot zu erfassen, und Percy erledigt den Rest in der Cloud. Der Review-Workflow findet in Percys Weboberflaeche statt: Sie sehen die Unterschiede, Sie genehmigen oder lehnen ab.
Fuer die genaue Konfiguration kann Ihr Desktop-KI den Snippet in drei Sekunden liefern — das ist sein Moment des Ruhms, lassen Sie ihn glaenzen, statt aus einer Dokumentation zu kopieren, die in sechs Monaten veraltet sein wird.
Die Grenzen
Die Kosten. Percy ist ein kostenpflichtiger Dienst. Der kostenlose Plan existiert, ist aber in der Anzahl der monatlichen Snapshots begrenzt. Fuer ein Team, das ernsthaft testet, steigen die Kosten schnell. Wir detaillieren hier keine Preistabellen — sie aendern sich regelmaessig — aber rechnen Sie mit einem nicht unerheblichen Budgetposten.
Die Cloud-Abhaengigkeit. Ihre Snapshots werden auf Percy-Servern gerendert. Wenn der Dienst ausfaellt, laufen Ihre Tests nicht mehr. Wenn BrowserStack (das Percy uebernommen hat) Preise oder Bedingungen aendert, haben Sie keinen Hebel.
Die CI-Latenz. Das DOM an einen externen Dienst senden, auf das Rendering warten, das Ergebnis zurueckholen — das fuegt Ihrer Pipeline Zeit hinzu. Bei zehn Tests nicht dramatisch, bei fuenfhundert spuerbar.
Das Vendor Lock-in. Sobald all Ihre Baselines bei Percy liegen, bedeutet eine Migration anderswohin, alles von Grund auf neu zu erstellen. Das ist die klassische Falle proprietaerer Cloud-Dienste.
Ansatz 3: Happo
Happo ist eine weniger bekannte Alternative zu Percy mit aehnlicher Positionierung: ein Cloud-Dienst, der Screenshots Ihrer Komponenten erfasst und vergleicht.
Die Integration mit Cypress existiert, ist aber weniger ausgereift als die von Percy. Das Produkt ist solide, das Team serioes, aber die Nutzerbasis ist kleiner. Weniger Community-Dokumentation, weniger Stack-Overflow-Antworten, weniger Erfahrungsberichte.
Dieselben Kosten- und Cloud-Abhaengigkeitsprobleme gelten.
Ansatz 4: Applitools Eyes
Applitools treibt das Konzept weiter mit seiner KI-basierten Vergleichstechnologie (ihr "Visual AI"). Statt Pixel-fuer-Pixel-Vergleich versucht der Algorithmus, "visuell signifikante" Unterschiede zu erkennen und kleinere Rendering-Variationen zu ignorieren.
Das klingt auf dem Papier verlockend. In der Praxis ist das Produkt leistungsstark aber komplex. Die Konfiguration ist nicht trivial, die Preisgestaltung intransparent, und die Abhaengigkeit von einem proprietaeren Dienst ist total. Fuer eine detaillierte Analyse lesen Sie unsere Applitools-Detailseite.
Das Grundproblem: Visual Testing als Add-on
Alle diese Ansaetze teilen einen strukturellen Mangel: Sie behandeln Visual Testing als Ergaenzung zum funktionalen Testing.
Sie haben Ihre Cypress-Suite. Sie pfropfen ein Plugin oder SDK drauf. Sie fuegen Aufrufe in Ihre bestehenden Tests ein. Visual Testing wird zum Parasiten des funktionalen Testing — abhaengig von derselben Infrastruktur, denselben Selektoren, demselben Code.
Wenn Cypress eine Major-Version aktualisiert, bricht Ihr Visual Testing Plugin. Wenn Ihr funktionaler Test den Ablauf aendert, wird Ihre visuelle Baseline obsolet. Wenn ein Entwickler einen Selektor aendert, fallen funktionaler UND visueller Test.
Das ist ein von Haus aus fragiles Modell.
Visual Testing verdient es, ein Buerger erster Klasse zu sein, kein blinder Passagier in der funktionalen Suite. Es beantwortet eine andere Frage ("Sieht das korrekt aus?" vs "Funktioniert das?") und sollte eigene Tools, eigene Workflows und eigene Baselines haben.
Was Ihre Cypress-Tests nicht sehen
Ein Cypress-Test prueft, ob der Button existiert und die richtige Aktion ausloest. Er prueft nicht, ob der Button sichtbar, korrekt ausgerichtet, in der richtigen Farbe und mit dem richtigen Padding ist — auf allen Breakpoints.
Visuelle Bugs sind tueckisch, weil sie alle funktionalen Tests bestehen. Das Formular funktioniert perfekt — aber das Label ueberlappt das Input-Feld auf Mobile. Das Dropdown-Menue oeffnet sich korrekt — aber es erscheint hinter einem anderen Element. Der angezeigte Preis ist korrekt — aber die Waehrung wird weiss auf weissem Hintergrund angezeigt.
Diese Bugs erreichen die Produktion, weil niemand sie systematisch sucht. Und sie kosten: an Glaubwuerdigkeit, an Conversions, an Support-Tickets.
Die Alternative: Visual Testing vom Code trennen
Was waere, wenn Visual Testing Cypress gar nicht brauchen wuerde?
Das ist die Position, die wir bei Delta-QA vertreten, und wir stehen voll dahinter. Visual Testing braucht keinen Code. Es braucht keine Plugins. Es braucht keine CSS-Selektoren und keine Webpack-Konfiguration.
Delta-QA funktioniert anders. Sie navigieren auf Ihrer Website, zeichnen einen Ablauf per Point-and-Click auf, und das Tool erfasst die Referenz-Screenshots. Bei jeder folgenden Ausfuehrung vergleicht es und zeigt Ihnen die Unterschiede in einer dedizierten Oberflaeche. Kein Code. Kein Plugin. Keine Abhaengigkeit von Cypress, Playwright oder irgendetwas anderem.
Das ist kein Kompromiss. Es ist eine andere Philosophie. Funktionales Testing und Visual Testing sind zwei verschiedene Disziplinen, die jeweils eigene Tools verdienen. Ihre Cypress-Suite prueft weiterhin, dass alles funktioniert. Delta-QA prueft, dass alles korrekt aussieht. Beide ergaenzen sich, ohne sich gegenseitig im Weg zu stehen.
Fuer QA-Teams, die nicht programmieren, ist das eine Befreiung. Fuer Entwickler ist es gewonnene Zeit. Fuer alle bedeutet es weniger False Positives und einen Review-Workflow, der Sinn ergibt.
FAQ
Kann Cypress Visual Testing ohne Plugin machen?
Nein. Cypress kann Screenshots mit cy.screenshot() erstellen, bietet aber keinen nativen Vergleichsmechanismus. Sie erhalten Bilder, aber der Vergleich mit Baselines, die Verwaltung von Toleranzschwellen und der Genehmigungsworkflow muessen ueber ein Plugin oder einen externen Dienst hinzugefuegt werden.
Welches ist das beste Cypress-Plugin fuer Visual Testing?
Es gibt keine universelle Antwort. cypress-image-snapshot ist das beliebteste Open-Source-Plugin, leidet aber unter Wartungs- und False-Positive-Problemen. Percy bietet die beste Benutzererfahrung, ist aber ein kostenpflichtiger Dienst. Das "Beste" haengt von Ihrem Budget, Ihrer False-Positive-Toleranz und Ihrer Bereitschaft ab, zusaetzlichen Code zu pflegen.
Ist Percy mit Cypress kostenlos?
Percy bietet einen kostenlosen Plan mit einer begrenzten Anzahl monatlicher Snapshots. Fuer serioesen professionellen Einsatz brauchen Sie einen kostenpflichtigen Plan. Die Tarife aendern sich regelmaessig, besuchen Sie deren Website fuer aktuelle Konditionen.
Kann man Cypress Visual Testing in CI/CD machen?
Ja, alle beschriebenen Ansaetze funktionieren in CI/CD. Aber hier multiplizieren sich die Probleme: Rendering-Unterschiede zwischen Umgebungen, Baseline-Management, Ausfuehrungszeit. CI verstaerkt jede Schwachstelle Ihres Visual Testing Setups.
Warum nicht einfach Playwright fuer Visual Testing verwenden?
Wenn Sie ein neues Projekt starten, ist Playwright mit seinem nativen toHaveScreenshot() tatsaechlich die bessere Wahl fuer code-basiertes Visual Testing. Aber wenn Sie bereits eine umfangreiche Cypress-Suite haben, ist Migration unrealistisch. Und selbst mit Playwright bleiben Sie im Paradigma des code-basierten Visual Testing, mit seinen Wartungs- und Zugaenglichkeitsgrenzen.
Kann Delta-QA Cypress-Tests ersetzen?
Nein, und das ist nicht das Ziel. Cypress brilliert beim funktionalen Testing: Pruefen, dass Interaktionen funktionieren, APIs korrekt antworten, die Geschaeftslogik eingehalten wird. Delta-QA konzentriert sich auf Visual Testing: Pruefen, dass die Oberflaeche korrekt aussieht. Beide Tools sind komplementaer, nicht konkurrierend.
Wie lange dauert es, Visual Testing in Cypress zu konfigurieren?
Mit cypress-image-snapshot rechnen Sie ein bis zwei Stunden fuer Installation und Basiskonfiguration, dann mehrere Tage zum Kalibrieren der Toleranzschwellen und Stabilisieren der Tests gegen False Positives. Mit Percy ist die technische Konfiguration schneller, aber das organisatorische Setup (Snapshot-Verwaltung, Review-Workflow, CI-Integration) braucht Zeit. Mit Delta-QA ist der erste Visual Test in wenigen Minuten einsatzbereit.
Fazit
Cypress ist ein exzellentes funktionales Testing Tool. Wir nutzen es, wir empfehlen es fuer das, was es gut macht. Aber zu behaupten, es wuerde Visual Testing zufriedenstellend abdecken, ist Selbstbetrug.
Plugins existieren. Sie funktionieren, mehr oder weniger. Aber sie sind fragil, teilweise schlecht gewartet, teuer bei anderen, und sie alle fuegen Komplexitaet an einer Stelle hinzu, die sie nicht braucht.
Visual Testing verdient mehr als ein Transplantat. Es verdient ein dediziertes Tool, das fuer genau dieses Problem konzipiert ist und dem gesamten Team zugaenglich ist — Entwicklern wie nicht-technischen QA-Mitarbeitern.