Zum Hauptinhalt springen

🖼 Visual Regression Testing

Visual Regression Tests prüfen, ob sich das sichtbare Erscheinungsbild einer Anwendung unbeabsichtigt verändert hat.

Sie vergleichen Screenshots (Baseline vs. aktuelle Version)
und erkennen visuelle Abweichungen automatisiert.

Während Unit Tests Logik prüfen und E2E-Tests Flows validieren, beantworten Visual Tests die Frage:

Sieht es noch so aus wie vorher?

1. Ziel und Einordnung​

1.1 Was ist Visual Regression Testing?​

Visual Regression Testing basiert auf:

  • Screenshot-Erstellung definierter Zustände
  • Pixel- oder DOM-basierter Vergleich
  • definierter Toleranzschwelle (Diff-Threshold)

Ein Test schlägt fehl, wenn die visuelle Abweichung größer als erlaubt ist.

1.2 Wofür ist es da?​

Visual Tests dienen der:

  • Absicherung von UI-Refactorings
  • Framework-Upgrades (z. B. Angular, React, Material)
  • Theme-/CSS-Änderungen
  • Erkennung unbeabsichtigter Layout-Verschiebungen
  • Sicherstellung konsistenter Design-Systeme

Sie sind besonders wertvoll bei:

  • großen UI-Bibliotheks-Upgrades
  • Design-System-Migrationen
  • globalen CSS-Änderungen

2. Praxisbeispiel: Angular Material v15​

Angular Material v15 führte:

  • neue MDC-basierte Komponenten
  • verpflichtendes neues Theming-Konzept
  • veränderte DOM-Strukturen
  • andere Default-Spacings und Typography

Ohne visuelle Regressionstests bedeutet das:

  • manuelle Klick-Tests
  • subjektive Wahrnehmung
  • keine vollständige Abdeckung
  • kein Nachweis für Stakeholder

Das Problem ist nicht funktional –
es ist visuell und konzeptionell.

3. Was Visual Tests leisten – und was nicht​

3.1 Was sie gut können​

  • Layout-Verschiebungen erkennen
  • Farbänderungen sichtbar machen
  • Spacing-/Margin-Regressionen erkennen
  • Typography-Änderungen feststellen
  • Versehentliche CSS-Überschreibungen finden

3.2 Was sie nicht können​

  • Logik validieren
  • Accessibility vollständig prüfen
  • Responsiveness ohne mehrere Viewports abdecken
  • Intentionsunterschiede bewerten (bewusst vs. unbewusst)

Ein Visual Test sagt:

„Etwas hat sich verändert.“

Er sagt nicht:

„Das ist falsch.“

4. Typische Werkzeuge​

  • Playwright + Screenshot Comparison
  • Cypress + Visual Plugin
  • Chromatic (Storybook)
  • Percy
  • Loki
  • Jest Snapshot (DOM-basiert)

Wichtig: Tooling ist sekundär – Disziplin ist entscheidend.

5. Test-Strategie​

5.1 Was sollte visuell getestet werden?​

Nicht jede Seite.

Sinnvoll sind:

  • Design-System-Komponenten (isoliert)
  • Kernseiten mit hoher Nutzung
  • Formulare mit komplexem Layout
  • Tabellen mit Sortierung/Filterung
  • Responsive Breakpoints
  • Dark-/Light-Theme

5.2 Component-Level vs Page-Level​

Component-Level (z. B. Storybook)

  • Stabiler
  • Weniger flakey
  • Bessere Isolation

Page-Level (E2E-basiert)

  • Realitätsnah
  • Höheres Risiko für Instabilität
  • Größerer Wartungsaufwand

Professionelle Setups kombinieren beides.

6. Flaky Visual Tests vermeiden​

Häufige Ursachen:

  • dynamische Daten
  • Datum/Uhrzeit
  • zufällige IDs
  • Animationen
  • nicht deterministische Fonts
  • externe Bilder

Regel:

Alles Nicht-Deterministische muss stabilisiert oder gemockt werden.

Beispiele:

  • Animationen deaktivieren
  • Uhrzeit einfrieren
  • Zufallswerte stubben
  • Testdaten fixieren

7. Governance über Qualitätsstufen​

Stufe 1​

  • keine visuellen Tests

Stufe 2​

  • visuelle Tests für Kernkomponenten

Stufe 3​

  • visuelle Regression als CI-Gate bei UI-Änderungen

Stufe 4​

  • dokumentierte Baselines
  • Review-Prozess bei UI-Diffs

Stufe 5​

  • Nachweisbarkeit von UI-Änderungen bei regulatorischer Relevanz

8. Visual Tests vs. Snapshot Tests​

Snapshot Tests (DOM)

  • vergleichen Struktur
  • anfällig für irrelevante Änderungen
  • schwer wartbar

Screenshot Tests

  • vergleichen visuelle Realität
  • näher an Benutzerwahrnehmung
  • aussagekräftiger bei Design-Regression

DOM-Snapshots sind kein Ersatz für visuelle Tests.

9. Definition of Done (UI-relevant)​

Ein UI-Refactoring gilt nicht als abgeschlossen, wenn:

  • kein visueller Vergleich existiert
  • nur manuell geprüft wurde
  • Baseline nicht aktualisiert wurde
  • bekannte visuelle Diffs ungeprüft bleiben

Kernaussage​

UI-Regressionen sind teuer, weil sie Vertrauen kosten.

Sie sind oft nicht funktional kritisch –
aber reputationskritisch.

Visual Regression Testing schafft:

  • Objektivität
  • Nachweisbarkeit
  • Sicherheit bei Framework-Upgrades
  • Schutz vor ungewollten Design-Drifts

In modernen Frontend-Systemen mit Design-Systemen, mehreren Teams und regelmäßigen Updates ist visuelle Regression kein Luxus – sie ist Design-Schutz.