Playwright für Screenshot-Tests verwenden

Ein Screenshot-Test vergleicht das aktuelle Aussehen einer Seite mit einem zuvor freigegebenen Bild. Weichen die Pixel um mehr als den erlaubten Wert ab, schlägt der Test fehl und zeigt die Abweichung an. Playwright Test enthält diese Funktion über expect(page).toHaveScreenshot() ohne zusätzliches Plugin. Das Verfahren heißt auch visuelles Regressionstesting.

Die Beispiele in diesem Leitfaden verwenden eine Test-Suite mit 12 Marketing- und App-Seiten, die in 3 Browser-Projekten getestet werden, sowie 8 gemeinsamen Komponenten. Alle Zahlen unten, von den Baseline-Anzahlen bis zu den Diff-Schwellenwerten, stammen aus dieser Suite.

Wann sich Screenshot-Tests lohnen

Visuelle Tests erkennen Probleme, die DOM-Assertions nicht erfassen: ein Stylesheet, das nicht geladen wurde, eine Schaltfläche, die aus dem sichtbaren Bereich verschoben wurde, oder eine Schrift, die auf eine Systemschrift zurückfällt. Der Pflegeaufwand lohnt sich, wenn:

• die UI ein Designsystem oder gemeinsame Komponenten hat, die auf vielen Seiten vorkommen
• sich CSS häufig ändert und Reviewer nicht jede Seite manuell prüfen können
• Layoutfehler bereits zuvor in die Produktion gelangt sind

Auf Seiten mit Live-Daten, Werbung oder nutzergenerierten Inhalten ist der Nutzen geringer als der Aufwand. Jeder Lauf liefert ein anderes Ergebnis, und die Suite erzeugt Rauschen.

Umfang der Suite vor dem Schreiben der Tests festlegen

Jede Assertion erzeugt pro Projekt eine Baseline. Die Beispiel-Suite hat 12 Assertions für ganze Seiten und 8 Assertions für Komponenten, die jeweils in 3 Projekten laufen. Daraus ergeben sich 60 PNG-Dateien, die erstellt, geprüft und im Repository gehalten werden müssen.

Seiten, die nicht in die Suite aufgenommen werden

Manche Seiten schlagen unabhängig von der Testschreibweise bei jedem Lauf fehl. Dazu gehören ein Dashboard mit Live-Diagrammen, ein Feed mit Nutzerbeiträgen und eine Seite mit rotierenden Bannern. Für solche Seiten testen Sie stattdessen den leeren Zustand oder eine Komponente mit festen Daten.

Das Beispielteam hat 5 Kandidatenseiten nicht in die Suite aufgenommen: 2 Dashboards, eine Blog-Übersicht mit wöchentlich neuen Beiträgen, eine Statusseite und eine Suchergebnisseite. Jede dieser Seiten wird über Element-Assertions für ihre gemeinsamen Teile abgedeckt. Die Liste der Vollseiten-Tests blieb bei 12.

Eine PNG-Datei einer langen Marketingseite kann ein Megabyte oder mehr groß sein. Sechzig Dateien dieser Größe vergrößern die Git-Historie bei jeder Aktualisierung der Baselines. Komponenten-Assertions erzeugen kleinere Dateien und ändern sich seltener, daher bilden sie den größten Teil der Suite.

Playwright Test installieren

npm init playwright@latest

Der Installer erstellt playwright.config.ts, einen Beispielordner für Tests und optional einen CI-Workflow und lädt anschließend die Browser herunter. Für Screenshot-Assertions sind keine weiteren Pakete erforderlich.

Die Playwright-Version festlegen

Jede Playwright-Version enthält bestimmte Browser-Builds. Ein Browser-Update kann die Textdarstellung leicht verändern und dadurch Screenshot-Tests fehlschlagen lassen, obwohl sich am Code nichts geändert hat. Legen Sie eine exakte Version in package.json fest und aktualisieren Sie sie in einem separaten Pull Request.

{
  "devDependencies": {
    "@playwright/test": "1.48.0"
  }
}

Bei einer Versionsänderung erzeugen Sie alle Baselines im selben Pull Request neu und prüfen sie gemeinsam. Eine Versionsänderung zusammen mit einer Funktionsänderung macht es unmöglich, die Ursache einer Abweichung zu bestimmen.

Den ersten Screenshot-Test erstellen

// tests/visual.spec.ts
import { test, expect } from '@playwright/test';

test('home page matches baseline', async ({ page }) => {
  await page.goto('https://example.com/');
  await expect(page).toHaveScreenshot('home.png', { fullPage: true });
});

Der erste Lauf hat keine Baseline zum Vergleich. Playwright speichert die Aufnahme als erwartetes Bild und lässt den Test fehlschlagen, damit die neue Baseline geprüft werden kann. Führen Sie npx playwright test erneut aus, besteht der Test gegen die gespeicherte Datei.

Weicht ein späterer Lauf ab, speichert Playwright das erwartete Bild, die tatsächliche Aufnahme und ein Diff-Bild, in dem die geänderten Pixel markiert sind. Der HTML-Bericht aus npx playwright show-report zeigt alle drei Bilder an.

Die 12 Seiten aus einer Liste testen

Zwölf einzelne Tests wiederholen dieselben Zeilen. Eine Liste mit Seiten und eine Schleife erzeugen einen benannten Test pro Seite. Der Testtitel enthält den Seitennamen, sodass Sie später mit -g eine einzelne Seite ansprechen können.

// tests/pages.visual.spec.ts
import { test, expect } from '@playwright/test';

const pages = [
  { name: 'home', path: '/' },
  { name: 'pricing', path: '/pricing' },
  { name: 'features', path: '/features' },
  { name: 'docs-index', path: '/docs' },
  // ...8 more entries
];

for (const p of pages) {
  test(`page ${p.name} matches baseline`, async ({ page }) => {
    await page.goto(p.path);
    await page.getByRole('heading', { level: 1 }).waitFor();
    await page.evaluate(() => document.fonts.ready);
    await expect(page).toHaveScreenshot(`${p.name}.png`, { fullPage: true });
  });
}

Relative Pfade benötigen in der Konfiguration eine baseURL. Der nächste Abschnitt ergänzt sie zusammen mit einem lokalen Webserver.

Gegen einen lokalen Build statt gegen die Produktion testen

Produktionsseiten ändern sich aus Gründen, die nichts mit dem getesteten Code zu tun haben: Inhaltsänderungen, A/B-Tests und Skripte von Drittanbietern. Ein lokaler Build des Branches zeigt nur die Änderungen des Branches. Die Option webServer startet den Build vor den Tests.

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: { baseURL: 'http://localhost:3000' },
  webServer: {
    command: 'npm run build && npm run start',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
    timeout: 120_000,
  },
});

Mit reuseExistingServer kann ein Entwickler bei lokalen Läufen seinen eigenen Server weiter laufen lassen. In der CI ist der Wert false, sodass der Job immer einen frischen Build startet.

Einen kleineren Teil der Seite testen

test('pricing card', async ({ page }) => {
  await page.goto('https://example.com/pricing');
  await expect(page.getByTestId('pro-plan')).toHaveScreenshot('pro-card.png');
});

Element-Assertions sind kleiner und schlagen seltener aus fachfremden Gründen fehl. Eine Änderung des Headers bringt den Test für die Preiskarte nicht zum Fehlschlagen. Verwenden Sie Vollseiten-Assertions für wenige zentrale Seiten und Element-Assertions für Komponenten.

Festlegen, welche Assertion jede Seite erhält

In der Beispiel-Suite teilen sich die 12 Seiten in 4 Seitentypen auf. Nur Seiten, die Menschen als Ganzes beurteilen, erhalten eine Vollseiten-Assertion. Seiten, die aus gemeinsamen Komponenten bestehen, erhalten stattdessen Element-Assertions für diese Komponenten.

Browser- und Gerätprojekte hinzufügen

Projekte in playwright.config.ts führen dieselben Tests in mehreren Browsern und Geräteprofilen aus.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'mobile', use: { ...devices['iPhone 13'] } },
  ],
});

Jedes Projekt hat eigene Baselines. Die Dateinamen enthalten Projekt und Plattform, zum Beispiel home-chromium-darwin.png. Drei Projekte bedeuten daher drei Baselines pro Assertion. Fügen Sie Projekte nur dort hinzu, wo sich das Layout tatsächlich unterscheidet.

Baselines in einem vorhersehbaren Ordner ablegen

Der Standardpfad legt einen Ordner -snapshots neben jede Testdatei. Bei mehreren Testdateien verteilen sich die Baselines dadurch über den gesamten Testbaum. Die Option snapshotPathTemplate verschiebt sie in einen Ordner pro Testdatei unterhalb eines gemeinsamen Stammverzeichnisses.

// playwright.config.ts
export default defineConfig({
  snapshotPathTemplate: '{testDir}/__screenshots__/{testFilePath}/{arg}{-projectName}{ext}',
});

Die Vorlage lässt das Plattformsuffix weg. Das funktioniert, weil jeder Lauf dasselbe Linux-Docker-Image verwendet. Falls manche Läufe weiterhin auf macOS stattfinden, behalten Sie {-snapshotSuffix} in der Vorlage, damit sich die beiden Plattformen nie eine Datei teilen.

Ein Reviewer öffnet einen Ordner und sieht alle Baselines einer Spec-Datei. Das Umbenennen einer Testdatei verschiebt ihre Baselines in einen neuen Ordner. Benennen Sie Testdateien daher nur in einem Pull Request um, der die Baselines ebenfalls neu erzeugt.

Den Zustand der Seite stabil halten

Ein Screenshot ist nur dann vergleichbar, wenn die Seite bei jedem Lauf denselben Zustand erreicht.

1. Warten Sie vor der Assertion auf ein sichtbares Element, etwa eine Überschrift oder ein geladenes Bild.
2. Verwenden Sie feste Testdaten statt Live-Konten.
3. Legen Sie in der Konfiguration eine feste Viewport-Größe fest.
4. Warten Sie auf Web-Fonts mit await page.evaluate(() => document.fonts.ready).

toHaveScreenshot wiederholt die Aufnahme bereits, bis zwei aufeinanderfolgende Aufnahmen übereinstimmen, und stoppt CSS-Animationen standardmäßig. Diese beiden Verhaltensweisen beseitigen einen großen Teil des Timing-Rauschens ohne zusätzlichen Code.

Auf ein Signal warten, nicht auf eine feste Zeit

Ein fester Aufruf page.waitForTimeout(3000) verlangsamt die Suite und schlägt auf einem langsamen Runner dennoch fehl. Wenn Sie auf ein bestimmtes Element warten, hängt die Assertion stattdessen vom Zustand der Seite ab. Das Warten auf die Überschrift in der Seitenschleife oben ist ein Beispiel dafür.

Das Warten, bis das Netzwerk ruhig ist, ist weniger zuverlässig, als es scheint. Seiten, die eine API abfragen oder eine Verbindung offen halten, erreichen diesen Zustand nie, und das Warten endet mit dem Timeout. Verwenden Sie besser ein Element, das erst nach dem Laden der Daten erscheint, etwa die erste Zeile einer Tabelle.

Lazy-Loading-Bilder unterhalb des sichtbaren Bereichs werden erst geladen, wenn sie in den Viewport scrollen. Eine Aufnahme der gesamten Seite zeigt dann leere Felder. Scrollen Sie vor der Assertion einmal bis zum Ende der Seite oder deaktivieren Sie Lazy Loading im Test-Build.

Zeit einfrieren und Skripte von Drittanbietern blockieren

Datumsangaben wie „Aktualisiert vor 3 Minuten“ ändern sich zwischen den Läufen. Die Clock-API legt die Zeit fest, die die Seite sieht. Skripte von Drittanbietern für Chat-Widgets und Analytics können Elemente spät einfügen. Deshalb blockiert der Test sie auf Netzwerkebene.

test.beforeEach(async ({ page }) => {
  await page.clock.setFixedTime(new Date('2026-05-01T10:00:00Z'));
  await page.route(/(analytics|chat-widget)\./, (route) => route.abort());
});

Das Blockieren eines Skripts entfernt auch alles, was es zeichnet. Das ist hier beabsichtigt: Der visuelle Test prüft das eigene Layout der Website, nicht das Widget.

Fehlerquellen und ihre Behebung

Die Beispiel-Suite schlug in den ersten zwei Wochen 9 Mal ohne Codeänderung fehl. Jeder Fehler ging auf eine von fünf Ursachen zurück. Die folgende Tabelle ordnet jeder Ursache die Änderung zu, die sie behebt.

Volatile Elemente ausblenden oder maskieren

await expect(page).toHaveScreenshot('dashboard.png', {
  mask: [page.locator('.timestamp'), page.locator('.user-avatar')],
});

Maskierte Bereiche werden in beiden Bildern mit einem einfarbigen Feld überdeckt, sodass ihr Inhalt ignoriert wird. Soll ein Element vollständig verschwinden, übergeben Sie mit der Option stylePath ein Stylesheet, das es ausblendet. Maskieren ist besser als Löschen, weil das Layout um das Element herum weiterhin geprüft wird.

Nach Rolle statt nach Layout maskieren

Ein Maskenlocator, der von Layout-Klassen abhängt, bricht, sobald sich das Markup ändert. Eine Test-ID oder eine barrierefreie Rolle bleibt bei Redesigns stabil. In der Beispiel-Suite trägt jedes volatile Element ein data-testid, das mit volatile- beginnt.

await expect(page).toHaveScreenshot('account.png', {
  mask: [page.locator('[data-testid^="volatile-"]')],
  maskColor: '#FF00FF',
});

Eine auffällige maskColor macht die maskierten Felder im Bericht deutlich sichtbar. Reviewer erkennen so auf einen Blick, welche Bereiche der Test ignoriert.

Den Diff-Schwellenwert sorgfältig festlegen

Option	Bedeutung
maxDiffPixels	Anzahl der Pixel, die sich unterscheiden dürfen.
maxDiffPixelRatio	Anteil der Pixel, die sich unterscheiden dürfen, von 0 bis 1.
threshold	Wie stark sich die Farbe eines Pixels unterscheiden muss, um zu zählen, von 0 bis 1. Standardwert 0,2.

Halten Sie die Toleranzen niedrig. Ein maxDiffPixelRatio von 0,01 erlaubt, dass sich 1 Prozent der Pixel ändern. Bei einer Vollseiten-Aufnahme mit 1280×4000 Pixeln sind das mehr als 50.000 Pixel. Damit lässt sich ein fehlendes Icon problemlos verbergen. Beginnen Sie mit maxDiffPixels um 100 und ändern Sie den Wert nur, wenn ein bestimmter Fehlalarm es erfordert.

Die Schwellenwert-Berechnung für eine Vollseiten-Aufnahme

Die folgenden Zahlen beziehen sich auf eine Aufnahme mit 1280 mal 4000 Pixeln, der Größe der Preisseite im Beispiel. Ein Icon mit 24 mal 24 Pixeln umfasst 576 Pixel. Bei einer Toleranz von 1 Prozent auf Basis des Verhältnisses könnte dieses Icon 88 Mal verschwinden, ohne dass der Test fehlschlägt.

Die Standardwerte einmal in der Konfiguration festlegen

Optionen pro Aufruf werden in neuen Tests leicht vergessen. Der Block expect.toHaveScreenshot in der Konfiguration legt Standardwerte für jede Assertion fest. Einzelne Tests können sie weiterhin überschreiben.

// playwright.config.ts
export default defineConfig({
  expect: {
    toHaveScreenshot: {
      maxDiffPixels: 100,
      threshold: 0.2,
      animations: 'disabled',
      caret: 'hide',
      scale: 'css',
    },
  },
});

scale: 'css' sorgt dafür, dass ein CSS-Pixel einem Bildpixel entspricht. Ein Geräteprofil mit hoher Pixeldichte verdoppelt die Bildgröße daher nicht. Die Baselines bleiben kleiner, und die Pixelzahlen oben bleiben aussagekräftig.

Baselines prüfen und aktualisieren

Wenn eine Designänderung beabsichtigt ist, erzeugen Sie die betroffenen Baselines neu:

npx playwright test --update-snapshots

Begrenzen Sie die Aktualisierung auf die fehlschlagenden Tests, indem Sie einen Dateinamen oder -g mit dem Testtitel angeben. Eine pauschale Aktualisierung der gesamten Suite macht versehentliche Änderungen leicht übersehbar.

npx playwright test tests/pages.visual.spec.ts -g "page pricing" --update-snapshots

Die drei Bilder in der richtigen Reihenfolge prüfen

Beginnen Sie mit dem tatsächlichen Bild, nicht mit dem Diff. Das tatsächliche Bild zeigt, ob die Seite für einen Menschen fehlerhaft aussieht. Öffnen Sie danach den Diff, um zu sehen, wo sich die Pixel geändert haben, und das erwartete Bild, um den früheren Zustand zu sehen.

Der Diff markiert geänderte Pixel in Rot. Ein dünner roter Rand um jeden Textblock deutet meist auf eine Änderung der Schrift oder des Kantenglättens hin und nicht auf einen Layoutfehler. Ein durchgehend rotes Rechteck an einer Stelle bedeutet meist, dass ein Element verschoben wurde, erschienen oder verschwunden ist.

Der HTML-Bericht bietet außerdem eine Schieberansicht zwischen erwartetem und tatsächlichem Bild. Wenn Sie den Schieber über den geänderten Bereich ziehen, werden kleine Verschiebungen, etwa eine Änderung des Randabstands um 2 Pixel, deutlicher als im Diff.

Der Lebenszyklus einer Baseline

Eine Baseline durchläuft jedes Mal denselben Zyklus, wenn sich die Seite absichtlich ändert. Der Zyklus enthält einen Entscheidungspunkt: ob die Abweichung beabsichtigt ist. Alle übrigen Schritte sind mechanisch.

Baseline-Änderungen im Pull Request prüfen

Eine geänderte PNG-Datei in einem Pull Request ist eine Codeänderung. GitHub und die meisten Review-Werkzeuge zeigen Bildunterschiede nebeneinander an. Die folgende Checkliste ist das, was die Reviewer im Beispielteam vor der Freigabe prüfen.

Screenshot-Tests in der CI ausführen

Auf macOS erzeugte Baselines stimmen nicht mit Aufnahmen auf einem Linux-Runner überein, da sich Schriften und Kantenglättung unterscheiden. Verlässlich ist es, Baselines und Vergleich in derselben Umgebung auszuführen, meist im offiziellen Playwright-Docker-Image in derselben Version wie das installierte Paket.

Ein praktikabler Ablauf:

1. Entwickler führen die visuelle Suite im Docker-Image aus, nicht direkt unter macOS.
2. Die CI verwendet dasselbe Image und lädt den HTML-Bericht bei einem Fehler als Artefakt hoch.
3. Beabsichtigte Änderungen erhalten neue Baselines, die zusammen mit der Codeänderung committet werden.
4. Reviewer prüfen die Bildunterschiede im Pull Request.

Baselines auf dem Mac in Docker erzeugen

Der Image-Tag muss zur festgelegten Playwright-Version passen. Eine Abweichung bringt die Unterschiede bei Schriften und Rendering zurück, die das Image eigentlich beseitigen soll. Führen Sie den Befehl im Projektstammverzeichnis aus.

docker run --rm --ipc=host -v "$(pwd)":/work -w /work \
  mcr.microsoft.com/playwright:v1.48.0-noble \
  /bin/bash -c "npm ci && npx playwright test --update-snapshots -g 'page pricing'"

Ein CI-Job für die visuelle Suite

Der Job läuft im selben Image, daher ist kein Schritt zum Herunterladen von Browsern nötig. Er lädt den Bericht nur hoch, wenn Tests fehlschlagen. Der Bericht enthält für jeden Fehler das erwartete, das tatsächliche und das Diff-Bild.

# .github/workflows/visual.yml
name: visual
on: pull_request
jobs:
  visual:
    runs-on: ubuntu-latest
    container:
      image: mcr.microsoft.com/playwright:v1.48.0-noble
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright test tests/*.visual.spec.ts
        env:
          HOME: /root
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

Im Beispiel dauert der gesamte Job etwa 5 Minuten. Wenn die 8 Komponenten-Assertions bei jedem Pull Request laufen und die 36 Seiten-Assertions nur auf dem Hauptbranch, sinkt die Dauer des Pull-Request-Jobs auf unter 3 Minuten.

Wo einfache Screenshot-Automatisierung weiterhin passt

Visuelle Tests beantworten eine Frage: Hat sich diese Seite gegenüber ihrer Baseline verändert? Sie erzeugen keine Sammlung zur Vorlage für ein Design-Meeting, einen Kundenbericht oder ein datiertes Archiv, und Personen außerhalb der Entwicklung führen sie selten aus.

Für diese Aufgaben ist ein einfaches Aufnahmewerkzeug einfacher. Temposhot Website Capture verarbeitet auf einem Mac eine Liste von URLs und erstellt Aufnahmen in Desktop 1920×1080, Tablet 768×1024 oder Mobil 390×844, ohne Testcode. Um zwei Aufnahmen optisch zu vergleichen, markiert der Compare Images Unterschiede im Browser. Der Eintrag Screenshot-Vergleich beschreibt das allgemeine Verfahren.

Zwei Werkzeuge für zwei unterschiedliche Fragen

Die visuelle Suite und ein Aufnahmewerkzeug laufen in einem Team häufig nebeneinander. Entwickler betreuen die Suite. Designer und Produktmanager verwenden die Aufnahmen für Reviews und Archive.

Häufige Fehler

• Baselines committen, die auf einem Laptop erzeugt wurden, und sie in der Linux-CI vergleichen.
• Ganze Seiten prüfen, die Datumsangaben, Karussells oder Werbung enthalten.
• Schwellenwerte erhöhen, um einen instabilen Test stummzuschalten, statt den Seitenzustand zu korrigieren.
• --update-snapshots für die gesamte Suite ausführen, obwohl sich nur eine Stelle beabsichtigt geändert hat.
• Viele Geräteprojekte hinzufügen, bevor die Desktop-Baselines stabil sind.

Einen fehlgeschlagenen visuellen Build untersuchen

Ein fehlgeschlagener visueller Job erfordert eine Entscheidung, keinen erneuten Lauf. Ein instabiler Test, der so lange wiederholt wird, bis er besteht, verdeckt die Ursache und lässt die nächste echte Regression durch. Die folgende Reihenfolge klärt die meisten Fehler in wenigen Minuten.

1. Laden Sie das Berichtsartefakt herunter und zählen Sie die fehlgeschlagenen Assertions.
2. Wenn jede Assertion in einem Projekt fehlgeschlagen ist, prüfen Sie zuerst auf eine Änderung von Browser oder Schrift in diesem Projekt.
3. Wenn eine Seite in allen 3 Projekten fehlgeschlagen ist, öffnen Sie ihr tatsächliches Bild. Die Ursache liegt meist in der Seite selbst.
4. Wenn eine Seite nur in einem Projekt fehlgeschlagen ist, suchen Sie nach einem browserspezifischen CSS-Problem oder einer Fehlerquelle aus der Tabelle oben.
5. Beheben Sie die Ursache oder aktualisieren Sie diese eine Baseline, aber nie beides im selben Commit.

Häufige Fragen

Wo werden die Baseline-Bilder gespeichert?

Standardmäßig in einem Ordner neben der Testdatei. Der Name leitet sich von der Testdatei ab und endet auf -snapshots. Mit der Konfigurationsoption snapshotPathTemplate ändern Sie den Speicherort.

Kann ich Screenshots ohne Playwright Test vergleichen?

Ja. Erstellen Sie die Aufnahmen mit einem beliebigen Werkzeug und vergleichen Sie die Dateien mit einem Werkzeug für Bildunterschiede. Playwright Test ergänzt diesen Vergleich um Wiederholungen, Maskierung und Berichte.

Sollten Screenshot-Tests bei jedem Pull Request laufen?

Für Assertions auf Komponentenebene meist ja. Große Vollseiten-Suiten können nach einem Zeitplan oder vor Releases laufen, wenn sie die Pipeline verlangsamen.

Warum besteht ein Test lokal, schlägt aber in der CI ohne Codeänderung fehl?

Die beiden Umgebungen rendern Text unterschiedlich. Schriften, Kantenglättung und Browser-Build können sich zwischen macOS und Linux unterscheiden. Führen Sie die Suite lokal und in der CI im selben Docker-Image aus.

Mit wie vielen Projekten sollte eine neue Suite beginnen?

Mit einem. Beginnen Sie mit einem einzelnen Desktop-Projekt, bis die Baselines ein bis zwei Wochen lang grün bleiben. Fügen Sie danach das Mobil-Projekt hinzu, weil sich mobile Layouts am stärksten unterscheiden. Einen zweiten Desktop-Browser fügen Sie zuletzt hinzu, und nur, wenn Nutzer browserspezifische Layoutfehler melden.

Kann die Suite Seiten hinter einer Anmeldung testen?

Ja. Melden Sie sich einmal in einem Setup-Projekt an, speichern Sie die Sitzung mit storageState und laden Sie diese Datei in den visuellen Projekten. Verwenden Sie ein eigenes Testkonto mit festen Daten, damit Namen und Zahlen auf der Seite bei jedem Lauf gleich bleiben.

Sollten Baselines mit Git LFS gespeichert werden?

Das lohnt sich, wenn die Suite Hunderte Bilder umfasst oder sich die PNG-Dateien häufig ändern. Bei einer Suite mit etwa 60 Dateien reicht meist normales Git. Prüfen Sie die Repository-Größe nach einigen Monaten mit Baseline-Aktualisierungen.

Referenzen

• Visuelle Vergleiche in Playwright
• Projekte in Playwright
• Playwright-Docker-Images

Keine Website-Screenshot-Automatisierung ohne Code nötig?

Wenn das Ziel eine Sammlung von Screenshots statt eines Bestanden- oder Fehlgeschlagen-Ergebnisses ist, führt Temposhot Website Capture eine URL-Liste lokal auf einem Mac aus. Siehe Automatisierung von Website-Screenshots oder den Schnellstart für Website Capture.