VizDiff
vizdiff.io · Coding
VizDiff ist ein selbst gehostetes Tool für visuelle Regressionstests bei Storybook. Es nimmt Komponenten in der CI auf, markiert Pixeländerungen und setzt Statusprüfungen auf GitLab oder GitHub vor dem Merge.
Über VizDiff
What Is VizDiff
VizDiff findet Oberflächenänderungen, die die reine Codeüberprüfung übersieht. Es setzt auf dem vorhandenen Storybook-Setup auf, nimmt bei jedem Commit einen Screenshot jeder Story auf und vergleicht den neuen Satz mit einer gespeicherten Basislinie. Alles, was sich verschoben hat, wird markiert, damit ein Mensch es freigibt oder ablehnt.
Das Tool läuft auf deiner eigenen Infrastruktur. Es gibt kein geteiltes Cloud-Konto, und die Screenshots liegen in deinem eigenen Speicher-Bucket. Das sind visuelle Regressionstests, ohne die Oberfläche an Dritte zu geben, und zugleich selbst gehostete visuelle Regression ohne Kompromisse. Storybook-Screenshot-Tests laufen dabei in der CI, und auch klassische Screenshot-Tests über die Storybook-Oberfläche bleiben im selben Werkzeug. Wenn dein Team Storybook bereits in GitLab oder GitHub baut, fügt sich VizDiff in die bestehende Pipeline ein, statt dich zum Umzug zu drängen.
Die wichtigste Einschränkung ist der Umfang. VizDiff versteht Storybook-Stories und kaum mehr, wer also ganze Seiten oder App-Abläufe testet, braucht etwas Breiteres. Außerdem setzt es voraus, dass du den Dienst selbst betreibst und pflegst, was es ausschließt, wenn du nichts betreiben willst.
Getting Started
- Melde dich bei VizDiff über deinen Identitätsanbieter an (Microsoft Entra oder SSO bei GitLab, GitHub OAuth bei GitHub).
- Füge ein Projekt hinzu und kopiere den Project Token, den es für dieses Repository erzeugt.
- Lege den Token als
VIZDIFF_PROJECT_TOKENin den Secrets oder Variablen deiner CI ab. - Nimm den Upload-Schritt in deine Pipeline auf und zeige auf das Storybook-Build-Verzeichnis, etwa
storybook-static. - Öffne eine Merge Request, prüfe die aufgenommenen Screenshots in VizDiff und gib den Build frei oder lehne ihn ab.
Produktinformationen
Ein kurzer Überblick über Preise, unterstützte Plattformen und die Leistung von VizDiff.
Am besten für
Die Nutzer, Aufgaben und Szenarien, für die dieses Tool am besten passt.
Nutzer
- Frontend-Teams, die Komponentenbibliotheken in Storybook bauen und Regressionen vor dem Merge abfangen wollen
- GitLab- oder GitHub-Nutzer, die bereits eine CI-Pipeline betreiben und kein separates Cloud-Konto wollen
- Organisationen mit strengen Datenregeln, die Screenshots auf der eigenen Infrastruktur halten müssen
- Einzelentwickler mit kleinen Komponentenprojekten, die ein Docker-Deployment selbst hochziehen können
Aufgaben
- Visuelle Regressionen in einer Pull Request abfangen, bevor der Code den Hauptzweig erreicht
- Nachvollziehen, welche Stories sich zwischen zwei Storybook-Builds geändert haben, und jede einzeln freigeben
- Eine geteilte Basislinie freigegebener Screenshots pflegen, mit der das ganze Team vergleicht
- Einen Merge automatisch blockieren, wenn ein Commit nicht freigegebene Oberflächenänderungen bringt
Szenarien
- Eine Komponente des Designsystems neu gestalten und genau sehen, welche anderen Ansichten dadurch gestört wurden
- Eine wachsende Komponentenbibliothek pflegen, in der eine kleine Stiländerung auf Dutzende Stories durchschlägt
- In einem verteilten Team arbeiten, in dem Prüfende die App nicht lokal starten können, um die Oberfläche anzusehen
- Einen Release-Prozess verschärfen, in dem UI-Fehler trotz grüner Unit-Tests weiter durchrutschen
Wichtigste Funktionen
Storybook Integration
VizDiff liest die Stories, die dein Team bereits geschrieben hat, also gibt es keine separate Testsuite zu pflegen. Wenn deine Pipeline Storybook baut, lädt die CLI das Ergebnis hoch und das Tool rendert pro Story einen Screenshot. Fügst du eine Komponente zu Storybook hinzu, erscheint sie im nächsten Vergleich ohne zusätzliche Konfiguration.
GitLab and GitHub Status Checks
Das Tool setzt einen Commit-Status auf GitLab-Merge-Requests oder eine Prüfung auf GitHub-Pull-Requests. Diese Prüfung bleibt offen, während Screenshots gerendert werden und während jemand die neuen oder geänderten ansehen muss. Hat sich nichts geändert, springt sie von selbst auf Erfolg, sodass Routine-Commits ohne Zutun durchlaufen.
Pixel-Level Diff Views
Jede geänderte Story öffnet sich in einem Vergleichsdialog mit den Ansichten Old, New, Diff und 2-Up. Die Diff-Ansicht wirkt als Pixel-Diff-Tool und hebt verschobene Pixel hervor, und der 2-Up-Modus stellt beide Versionen nebeneinander. Mit den Pfeiltasten springst du durch den Satz, was zählt, wenn ein einzelner Branch Dutzende Stories berührt.
Shared Baselines
Freigegebene Screenshots werden zur Basislinie, gegen die der nächste Build verglichen wird, und das ganze Team arbeitet mit demselben Satz. Die Screenshots liegen in deinem eigenen S3-kompatiblen Bucket, sodass die Referenzbilder deine Infrastruktur nie verlassen. Ein Branch von einem Commit mit freigegebenen Screenshots hält den Vergleich aussagekräftig, statt ihn auf alles-neu zurückzusetzen.
Self-Hosted Deployment
VizDiff wird als Open-Source-Projekt unter MIT-Lizenz ausgeliefert und läuft als drei Dienste (api, worker, frontend) auf PostgreSQL und einem Bucket, das du bereitstellst. Versionierte Multi-Arch-Images werden in der GitHub Container Registry veröffentlicht, und sowohl eine Docker-Compose-Datei als auch ein Helm-Chart decken die Einrichtung ab. Kein Anbieterkonto und keine Gebühr pro Nutzer.
Vor- und Nachteile
Vorteile
- Screenshots und Basislinien bleiben auf deiner eigenen Infrastruktur, was zu strengen Datenrichtlinien passt
- Arbeitet mit dem Storybook-Build, den deine Pipeline ohnehin erzeugt, sodass die Einführung fast nur eine CI-Änderung ist
- Statusprüfungen blockieren Merges von selbst und geben sich frei, wenn sich nichts geändert hat
- Open Source unter MIT, ohne Gebühr pro Nutzer zum Verhandeln
- UI-Regressionstests im Hintergrund, sodass Prüfende nur hinschauen, wenn sich etwas bewegt
- GitLab und GitHub werden unterstützt, auch selbst gehostete GitLab-Instanzen
Nachteile
- Die Einrichtung verlangt, das Deployment zu betreiben und zu pflegen, also Docker, PostgreSQL und ein Speicher-Bucket
- Testet nur Storybook-Stories, ganze Seiten und mehrstufige Abläufe bleiben außen vor
- Der erste Lauf eines Branches legt nur eine Basislinie an, die ersten Commits zeigen also alles als neu
- Die Anmeldung hängt an einem externen Identitätsanbieter, ein rein lokales Team hat also mehr zu verdrahten
Häufige Fragen
Es nimmt bei jedem Lauf deiner CI-Pipeline einen Screenshot jeder Storybook-Story auf, vergleicht die Ergebnisse mit den freigegebenen Basislinien und meldet, welche sich geändert haben. Diese Änderungen erscheinen als Statusprüfung in deiner Merge Request oder Pull Request, wo eine Kollegin sie freigibt oder ablehnt.
Ähnliche Inhalte
Entdecke passende Tools, Skills und Artikel zu VizDiff.
Alternativen zu VizDiff
Forefront
Forefront · CodingForefront ist eine Webplattform zum Bauen mit Open-Source-KI. Sie lassen sich führende Open-Source-Sprachmodelle mit eigenen Daten feintunen, ihre Leistung bewerten und sie über eine API ausführen oder exportieren, um sie selbst zu hosten. Entwickler, die den Komfort einer geschlossenen Plattform wollen, aber darauf bestehen, ihre Modelle und Daten zu besitzen, sind hier die Zielgruppe.
Startkit
StartKit.AI · CodingStartkit ist ein Boilerplate zum Bauen von KI-SaaS-Produkten und KI-Wrappern. Man kann es sich als KI-Startup-Boilerplate vorstellen, bei dem die langweiligen Teile schon verdrahtet sind: Authentifizierung, Zahlungen über Stripe und Lemon Squeezy, Nutzungslimits, transaktionale E-Mail und ein KI-API-Starter-Kit, das mit OpenAI, Anthropic, Groq oder Llama spricht. Man klont das Repository, setzt seinen Preis und kümmert sich um den Teil des Produkts, für den Menschen wirklich bezahlen. Es basiert auf Next.js über React und Tailwind, deshalb fühlt sich ein Großteil des Boilerplate-Codes schon vertraut an.
Testim
Tricentis · CodingTestim ist eine KI-gestützte Plattform für Testautomatisierung, mit der man End-to-End-Tests für Web-, Mobile- und Salesforce-Anwendungen baut und ausführt. Sie setzt auf maschinelles Lernen, um Tests stabil zu halten, wenn sich eine Oberfläche ändert, sodass Teams weniger Zeit mit der Reparatur kaputter Selektoren verbringen. Nicht schlecht für ein Tool für automatisierte Tests, das Sie heute schon nutzen können. Sie erstellen Tests, indem Sie Aktionen im Browser aufzeichnen, und fügen danach JavaScript hinzu, wenn Sie mehr Kontrolle brauchen. Für ein beschäftigtes QA-Team eine solide Wahl.