HTML-Snapshot-Tests

Snapshot-Tests speichern bei der ersten Ausführung die gerenderte Ausgabe einer Komponente oder Seite. Bei nachfolgenden Ausführungen vergleichen sie die neue Ausgabe mit dem gespeicherten Snapshot. Jede Änderung an der HTML-Ausgabe lässt den Test fehlschlagen, bis der Snapshot bewusst aktualisiert wird.

Der Jest-Matcher toMatchSnapshot() serialisiert einen Wert (einschließlich als HTML gerendertem JSX) und vergleicht ihn mit einer gespeicherten Datei. npx jest -u aktualisiert Snapshots, wenn beabsichtigte Änderungen vorgenommen wurden. Tests dienen als Sicherheitsnetz gegen unbeabsichtigte Änderungen an der Darstellung.

Storybook Test Runner führt jede Story aus und erstellt über axe (Barrierefreiheit) sowie die Serialisierung des DOM Snapshots ihrer Ausgabe. In Kombination mit Chromatic ergänzt er dies um visuelle Regressionstests – pixelgenaue Unterschiede zusätzlich zu DOM-Unterschieden.

Percy und Chromatic erstellen Bild-Snapshots gerenderter Seiten und zeigen visuelle Unterschiede auf. Sie erkennen CSS-Regressionen, die DOM-Snapshots übersehen (einen Schriftaustausch, eine Änderung des Außenabstands oder eine Farbverschiebung). Kombinieren Sie DOM-Snapshots (günstig, schnell) mit visuellen Snapshots (aufwendig, umfassend).

Snapshots, die sich „zu leicht“ ändern, werden zu störendem Rauschen. Vermeiden Sie Snapshots für instabile Werte (Datumsangaben, ids, zufällige Schlüssel). Verwenden Sie die Property-Matcher von Jest (expect.any(String)) für Felder, die sich zwischen den Ausführungen berechtigterweise ändern. Halten Sie Snapshots klein und fokussiert.

Unterschiede in Snapshot-Dateien innerhalb von Pull Requests sind ein gleichwertiger Bestandteil des Review-Materials. Reviewer überprüfen, ob Änderungen am DOM beabsichtigt und sinnvoll sind – und erkennen unbeabsichtigte Folgeeffekte einer „einfachen“ CSS-Änderung. Behandeln Sie Snapshot-Unterschiede wie jeden anderen Diff.

Snapshots großer Renderings auf Seitenebene sind fragil – jede kleine Änderung führt zu einem riesigen Diff. Erstellen Sie Snapshots auf Komponentenebene: für jeden Button, jede Card und jedes FormField. Für das Rendering auf Seitenebene eignen sich stattdessen visuelle Regressionstests.

Wählen Sie, wie serialisiert werden soll: vollständiges HTML, vereinfachtes DOM, nur Props oder der Accessibility Tree. Jedes Format erkennt andere Regressionen. Bei UI-Komponenten ist vollständiges HTML am gründlichsten; bei Props-gesteuerter Logik ist die Variante mit ausschließlich Props kostengünstiger und erzeugt nur selten Fehlalarme.

Die häufigste Ursache ist ein Refactoring, das strukturell anderes, aber inhaltlich gleichwertiges HTML erzeugt. Prüfen Sie den Diff: Ist die Änderung beabsichtigt und sinnvoll, aktualisieren Sie den Snapshot. War sie nicht erwartet, beheben Sie den zugrunde liegenden Code. Führen Sie niemals blind jest -u aus, ohne den Diff zu prüfen.

Tools für visuelle Regressionstests rendern in mehreren Browsern und melden browserspezifische Unterschiede. Nutzen Sie dies, um CSS zu erkennen, das in Safari anders gerendert wird als in Chrome – ein häufiges Problem bei neuen Layoutfunktionen in der frühen Einführungsphase. Ohne browserübergreifende Snapshots werden solche Regressionen erst bei manueller Qualitätssicherung entdeckt.

Snapshot-Tests sind notwendig, aber nicht ausreichend. Sie erkennen unbeabsichtigte Änderungen am Rendering, jedoch keine Logikfehler (etwa dass ein Klick auf den Button nicht die richtige Aktion ausführt). Kombinieren Sie sie mit Unit-Tests für das Verhalten und End-to-End-Tests für Benutzerabläufe – jede Ebene erkennt andere Fehler.

Snapshot-Tests sind schnell – sie vergleichen Zeichenketten oder Dateien. Visuelle Regressionstests sind langsamer (sie rendern Pixel, vergleichen Bilder und laufen häufig in mehreren Browsern). Führen Sie Snapshots bei jedem CI-Build aus; visuelle Regressionstests bei jedem PR, je nach CI-Budget möglicherweise jedoch nicht bei jedem Commit.

Warum werden DOM-Snapshot-Tests üblicherweise durch visuelle Regressionstests wie Percy oder Chromatic ergänzt?

Snapshot-Testing erfasst beim ersten Durchlauf das gerenderte HTML und meldet bei nachfolgenden Durchläufen jede Änderung. Verwenden Sie Jest toMatchSnapshot für das Komponenten-DOM, Storybook Test Runner für Stories und Percy/Chromatic für visuelle Regressionen auf Pixelebene. Erstellen Sie Snapshots auf Komponentenebene (nicht auf Seitenebene), schließen Sie instabile Werte aus und prüfen Sie Diffs in PRs sorgfältig. Kombinieren Sie dies mit Unit- und End-to-End-Tests, um eine vollständige Abdeckung zu erreichen.