Ein Screenshot-Update ist eine Prüfentscheidung.

Ein Screenshotcheck scheitert, nachdem eine Schaltfläche verschwindet. Die Referenz zu ersetzen bringt Grün zurück, kann das Verschwinden aber zur Norm machen. Der Befehl entscheidet nicht, ob es gewollt war. Ein Update ist eine Produktentscheidung, keine Reparatur durch das Bildwerkzeug.

Dieser Leitfaden folgt der Playwright-Screenshotdokumentation mit einer erfundenen lokalen Karte. Verglichen wird die unveränderte Vorlage in kontrollierter Umgebung. Keine Produktionsoberfläche, Barrierefreiheitszertifizierung oder Leistungsmessung. Was akzeptiert die neue Referenz?

Benenne Referenz und Umgebung

Die Assertion vergleicht ein Bild mit einer Referenz. Der Leitfaden beschreibt Erzeugen beim ersten Lauf und spätere Vergleiche. Der Name muss die Ansicht identifizieren, damit kein fremdes Bild sie ersetzt.

await page.setContent(`
  <main aria-label="Demo preference card">
    <h1>Demo preference</h1>
    <button>Keep demo setting</button>
  </main>
`);
await expect(page.getByRole('main')).toHaveScreenshot('demo-card.png');

Testläufer und importiertes expect sind nötig. Nur eine Region wird geprüft, nicht das Produkt. Stabiles Styling und festes Viewport gehören zur Vorlage. Die Referenz entsteht bewusst und wird in einem getrennten Lauf verglichen.

Betriebssystem, Browser, Einstellungen, Hardware und Headless-Modus können das Rendering ändern. Erzeuge und vergleiche in derselben Umgebung. Eine andere Plattform braucht vielleicht eine eigene Referenz, keine größere Fehlertoleranz, die wichtige Änderungen verdeckt.

Lies die Differenz vor dem Ersetzen

Prüfe erwartetes und aktuelles Bild sowie die sichtbare Änderung. Neue Anforderung, Umgebungsdrift und Regression verlangen verschiedene Maßnahmen trotz desselben roten Ergebnisses.

update-snapshots ist dokumentiert. Nutze es nach Verständnis und Freigabe im Teamprozess. Neue Referenzen ändern erwartetes Verhalten. Aktualisiere nicht pauschal, um alle Abweichungen ruhigzustellen.

Ein entfernter Button kann korrektes Redesign oder schwerer Fehler sein. Pixel wissen das nicht. Verbinde Änderung und Anforderung; behalte einen funktionalen Check, wenn Verfügbarkeit wichtig ist.

Begrenze den Vergleich ehrlich

Eine Region belegt diese Region in der gewählten Einrichtung. Keine Offscreen-Inhalte, anderen Viewports oder Serverergebnisse. Wähle nach Frage, nicht nach einfachem Grün.

Toleranzen und Screenshotstile reduzieren Rauschen, ändern aber relevante Unterschiede. Benenne ausgeschlossene Elemente und Schwellen. Verstecke nie das zu schützende Element.

Die unveränderte Karte wird verglichen; ein weiteres Bild mit geändertem Buttontext dient der Pixelprüfung. Es wird nicht als Referenz angenommen. Gezeigt werden sichtbare Änderung und stabiler Vergleich, keine vollständige Strategie.

Bewahre eine prüfbare Entscheidung

Notiere Ansicht, Umgebung, gewollte Differenz und Entscheidung. Erhalte Historie für den nächsten Entwickler. Entferne private Datensätze vor Ablage im Repository.

AnyTest beschreibt Erkundung und prüfbare Tests. Frage nach Vergleich und Freigabe der neuen Erwartung. Keine AnyTest-Baselinefunktion wird behauptet. Der Befehl schreibt die Datei; die Prüfung verantwortet ihren Sinn.