Wie testet man Safari mit Playwright? Praxisroute für Studierende 2026

Befund: Playwright kann Webseiten mit WebKit automatisiert prüfen, aber Playwrights WebKit ist nicht Safari selbst. Schnellster Weg: Führen Sie zuerst WebKit-Tests aus; wenn Ihre Abgabe echtes Safari-Verhalten belegen muss, prüfen Sie die betroffenen Abläufe zusätzlich in Safari auf macOS.

Dieser Leitfaden ist für Sie gedacht, wenn Sie unter Windows an einem Frontend-Kursprojekt arbeiten und automatische Browsertests ergänzen möchten. Auch wenn Sie einen sichtbaren Unterschied zwischen Safari und einem anderen Browser untersuchen, hilft Ihnen die Schrittfolge, einen Testfehler von einem tatsächlichen Darstellungsproblem zu trennen. Wenn Sie Testergebnisse abgeben müssen, erfahren Sie außerdem, wie Sie den Umfang Ihrer Prüfung ehrlich dokumentieren.

Ist Playwrights WebKit dasselbe wie Safari?

Nein. Playwright steuert WebKit, eine Browser-Engine, die auch für Safari wichtig ist. Die Playwright-Dokumentation beschreibt die eigene WebKit-Version als aus dem WebKit-Hauptprojekt abgeleitet. Sie ist jedoch nicht der Markenbrowser Safari und kann ihn nicht starten. Deshalb dürfen Sie einen bestandenen WebKit-Test nicht als Nachweis dafür ausgeben, dass Sie Safari selbst getestet haben. Playwright erklärt die unterstützten Browser und die Beziehung zu WebKit.

Für Ihre Entscheidung sind drei Ebenen hilfreich:

Browser-Engine: Sie verarbeitet unter anderem HTML, CSS und JavaScript. WebKit ist die Engine, die Playwright in dieser Testumgebung steuert.
Browser-Anwendung: Safari ist eine konkrete Anwendung mit eigener Integration ins Betriebssystem. Ihre Darstellung und Funktionen können von der Umgebung abhängen.
Automatisierter Test: Das Skript öffnet Seiten und prüft festgelegte Bedingungen. Es kontrolliert nicht automatisch jede mögliche Darstellung, jedes Gerät oder jede Bedienweise.

Playwright dokumentiert Unterstützung für **drei Browser-Engines: Chromium, WebKit und Firefox**. Das ist nützlich, wenn Sie Unterschiede zwischen diesen Testumgebungen früh entdecken wollen. Es bedeutet aber nicht, dass ein Lauf pro Engine jedes reale Gerät oder jede Version des jeweiligen Markenbrowsers abdeckt. Die Zahl der unterstützten Engines und ihre Grenzen sind in der [offiziellen Browserübersicht](https://playwright.dev/docs/browsers) beschrieben.

Die Unterscheidung wird besonders wichtig, wenn Sie einen Screenshot, einen Bericht oder ein Testergebnis für eine Lehrveranstaltung einreichen. Schreiben Sie präzise, was tatsächlich lief: etwa „automatisierter Test mit Playwright WebKit unter Windows“. Schreiben Sie nicht „Safari-Test“, wenn Sie Safari nicht geöffnet und den Ablauf darin geprüft haben.

Was können Sie unter Windows mit Playwright prüfen?

Unter Windows können Sie mit Playwright einen WebKit-Testlauf als automatisierte Vorprüfung einrichten. Das eignet sich für Fragen wie: Wird die Seite geladen? Lässt sich ein Menü öffnen? Wird nach dem Absenden eines Formulars eine Bestätigung angezeigt? Playwright stellt die erforderlichen Browser-Binärdateien über seine Installationsschritte bereit. Prüfen Sie die aktuellen Plattform- und Installationshinweise in der offiziellen Installationsanleitung, statt Anleitungen für eine andere Projektversion zu übernehmen.

Beginnen Sie mit einem funktionierenden Projekt. Wenn Ihre Seite bereits lokal läuft, müssen Sie das Projekt nicht für Playwright neu erstellen. Installieren und konfigurieren Sie Playwright nach der Anleitung für Ihre vorhandene Umgebung. Bei einem neuen Testprojekt bietet die offizielle Anleitung einen Einrichtungsweg, der die Projektkonfiguration anlegt. Welche Fragen der Einrichtungsdialog stellt, kann sich mit der Dokumentation ändern.

Richten Sie die Prüfung in klaren Schritten ein

Legen Sie das Prüfergebnis fest. Schreiben Sie einen Satz auf, der beschreibt, was Sie nachweisen möchten. „Das Kontaktformular zeigt nach dem Absenden eine Erfolgsmeldung“ ist überprüfbar; „die Website funktioniert“ ist zu ungenau.

Starten Sie Ihre Anwendung. Verwenden Sie den Startbefehl, den Ihr Kursprojekt bereits nutzt. Achten Sie darauf, dass die lokale Adresse erreichbar ist. Wenn Playwright eine leere oder falsche Seite öffnet, prüfen Sie zuerst diesen Schritt, bevor Sie Safari-Kompatibilität vermuten.

Richten Sie Playwright ein. Folgen Sie der offiziellen Installationsanleitung. Installieren Sie die Browser, die Ihre Projektkonfiguration tatsächlich benötigt. Der konkrete Befehl hängt davon ab, wie Ihr Projekt eingerichtet wurde; übernehmen Sie deshalb die zur aktuellen Anleitung passende Variante.

Erstellen Sie einen kurzen Test für eine wichtige Aufgabe. Beginnen Sie nicht damit, jede Unterseite und jedes Detail abzusichern. Wählen Sie einen Ablauf, der für Ihr Projekt zählt, etwa Navigation, Suche oder Formularabsendung.

Wählen Sie stabile Elemente aus. Verwenden Sie möglichst zugängliche Namen oder eindeutige Kennzeichnungen statt fragiler Positionen wie „das dritte Element von oben“. Die Playwright-Anleitung für Locators erklärt, wie Sie Elemente verlässlich ansprechen.

Formulieren Sie eine überprüfbare Erwartung. Eine Assertion ist eine automatische Antwortkontrolle: Das Skript fragt beispielsweise, ob eine Überschrift sichtbar ist. Die Dokumentation zu Assertions zeigt, wie solche Prüfungen aufgebaut sind.

Führen Sie den Test aus und lesen Sie das Ergebnis. Die Anleitung zum Ausführen von Tests beschreibt den Ablauf und die verfügbaren Optionen. Wenn ein Test scheitert, notieren Sie die Fehlermeldung, bevor Sie Änderungen an der Seite vornehmen.

Ein kleines Beispiel macht den Unterschied zwischen einer vagen und einer brauchbaren Prüfung sichtbar. „Die Schaltfläche ist da“ kontrolliert nur einen Teil der Aufgabe. Ein besserer Test prüft, ob Sie die Schaltfläche über einen verständlichen Namen finden, sie betätigen und anschließend die erwartete Meldung sehen können. Playwright wartet bei vielen Aktionen auf geeignete Bedingungen; dadurch muss ein Test nicht einfach eine feste Wartezeit einbauen. Die genauen Bedingungen und Grenzen beschreibt die [Dokumentation zu automatischen Aktionen und Wartebedingungen](https://playwright.dev/docs/actionability).

So führen Sie ausschließlich WebKit-Tests aus

Wenn Ihr Testprojekt mehrere Browser-Projekte enthält, können Sie gezielt das konfigurierte WebKit-Projekt auswählen. Die genaue Projektbezeichnung steht in Ihrer Konfigurationsdatei. In der offiziellen Anleitung für Playwright-Projekte wird erklärt, wie Playwright Projekte definiert; die Anleitung zum Ausführen von Tests beschreibt den Filter für ein bestimmtes Projekt.

Im Terminal sieht die Auswahl beispielsweise so aus:

npx playwright test --project=webkit

Dieser Befehl funktioniert nur, wenn Ihre Konfiguration ein Projekt mit dem Namen webkit enthält. Heißt Ihr Projekt anders, ersetzen Sie den Namen durch die Bezeichnung aus Ihrer Konfiguration. Wird kein passendes Projekt gefunden, ist das zunächst ein Konfigurationsproblem und kein Hinweis auf einen Safari-Fehler.

Prüfen Sie bei Bedarf, ob Playwright die Projektbezeichnung erkennt, bevor Sie die Testergebnisse interpretieren. Notieren Sie anschließend, welches Projekt Sie tatsächlich ausgeführt haben. So vermeiden Sie eine häufige Verwechslung: Ein Testlauf, der versehentlich nur Chromium verwendet, sagt nichts über das Ergebnis des WebKit-Projekts aus.

Prüfschritt	Was Sie damit herausfinden	Was daraus nicht folgt
WebKit-Test unter Windows	Ob ein festgelegter Ablauf in der konfigurierten Playwright-WebKit-Umgebung funktioniert	Dass Safari unter macOS identisch reagiert
Vergleich mit Chromium	Ob derselbe Test in zwei konfigurierten Projekten unterschiedlich ausfällt	Dass bereits die Ursache des Unterschieds feststeht
Safari-Test auf macOS	Ob der festgelegte Ablauf in der Safari-Anwendung der verwendeten Umgebung funktioniert	Dass jede Safari-Version und jedes Gerät geprüft wurde

Nutzen Sie diese Gegenüberstellung als Nachweisgrenze, nicht als Rangliste. Wenn der Kurs lediglich erwartet, dass Sie automatisierte Tests für mehrere Browser-Engines erstellen, kann der WebKit-Lauf ein sinnvoller Bestandteil Ihrer Abgabe sein. Wenn ausdrücklich Safari verlangt wird, benötigen Sie zusätzlich eine Prüfung im Safari-Browser.

So ordnen Sie einen fehlgeschlagenen Test ein

Ein roter Testbericht beweist für sich allein nicht, dass Ihre Webseite mit Safari inkompatibel ist. Zuerst muss klar sein, ob der Fehler in der Testumgebung, im Skript oder in der Seite steckt. Gehen Sie in einer festen Reihenfolge vor, damit Sie nicht vorschnell den falschen Teil ändern.

Wiederholen Sie denselben Test. Achten Sie darauf, dass Anwendung, Testdaten und Browser-Projekt gleich bleiben. Wenn schon der nächste Lauf ein anderes Ergebnis liefert, dokumentieren Sie diese Abweichung, statt ein einmaliges Ergebnis als gesicherte Ursache darzustellen.

Kontrollieren Sie die Adresse und den Seitenstart. Öffnet der Test die erwartete Seite? Wird eine Fehlermeldung des Entwicklungsservers angezeigt? Ein falscher Startbefehl oder ein nicht erreichbarer Server kann den gesamten Test zum Scheitern bringen, bevor die eigentliche Prüfung beginnt.

Lesen Sie den Fehler an der betroffenen Testzeile. Schlägt das Finden eines Elements fehl, prüfen Sie zuerst den Locator. Wird ein Element gefunden, aber eine Assertion schlägt fehl, prüfen Sie den tatsächlichen Text, den Zustand und den Zeitpunkt der Erwartung. Die Locator- und Assertion-Dokumentation hilft, diese Fälle auseinanderzuhalten.

Vergleichen Sie dieselbe Aufgabe in Chromium und WebKit. Verwenden Sie denselben Projektstand und denselben Test. Funktioniert die Aktion in beiden, aber sieht die Seite anders aus, brauchen Sie eine gezielte visuelle Prüfung. Scheitert nur WebKit, haben Sie einen reproduzierbaren Unterschied gefunden, aber noch nicht automatisch bewiesen, dass Safari denselben Fehler zeigt.

Sichern Sie Hinweise zum Ablauf. Ein Trace kann zeigen, welche Aktionen der Test durchgeführt hat und an welcher Stelle er hängen blieb. Der Trace Viewer ist dafür vorgesehen. Nutzen Sie ihn, wenn die Fehlermeldung allein nicht erkennen lässt, ob der Locator, die Navigation oder eine Erwartung die Ursache war.

Beobachtung	Als Erstes prüfen	Sichere Aussage für Ihren Bericht
Seite öffnet sich nicht	Startbefehl, lokale Adresse und Serverausgabe	„Der Test erreichte die erwartete Seite nicht.“
Element wird nicht gefunden	Locator, zugänglicher Name und tatsächliche Seitenstruktur	„Die Auswahl des Elements muss geprüft werden.“
Assertion meldet falschen Zustand	Erwarteter Text, Sichtbarkeit und tatsächliches Ergebnis	„Die festgelegte Erwartung wurde nicht erfüllt.“
WebKit weicht von Chromium ab	Derselbe Ablauf, derselbe Projektstand und relevante Browserausgabe	„Im WebKit-Projekt trat eine Abweichung auf; Safari ist damit noch nicht bestätigt.“

Ändern Sie nicht gleichzeitig Testskript, Seitenlayout und Browserkonfiguration. Wenn danach das Ergebnis anders ist, können Sie kaum noch sagen, welche Änderung den Ausschlag gegeben hat.

Besondere Aufmerksamkeit verdienen Layout, Schriftbild und Medienwiedergabe. Ein automatisierter Test kann prüfen, ob ein Element vorhanden ist oder ob eine Aktion funktioniert. Er bewertet aber nicht automatisch, ob ein Zeilenumbruch für Ihr Kursdesign richtig aussieht, ob eine Schrift auf einem bestimmten Gerät dieselbe Wirkung hat oder ob ein Medienformat in der vorgesehenen Umgebung abspielbar ist. Formulieren Sie deshalb konkrete Prüfaufgaben, statt aus einem bestandenen Funktionstest eine allgemeine Kompatibilitätsaussage abzuleiten.

Wann ist eine Prüfung in echtem Safari nötig?

Eine Safari-Prüfung auf macOS ist nötig, wenn die Abgabe ausdrücklich Ergebnisse aus der Safari-Anwendung verlangt oder wenn Ihre Frage von einer Safari-spezifischen Umgebung abhängt. Auch wenn Sie einen auffälligen Layout- oder Medienunterschied untersuchen und dieser für die Bewertung wichtig ist, sollten Sie den betroffenen Ablauf in Safari nachprüfen. Die Playwright-Dokumentation empfiehlt macOS, wenn Sie eine Safari-nähere Erfahrung benötigen; sie macht zugleich deutlich, dass Playwright-WebKit nicht der Markenbrowser Safari ist.

Nutzen Sie die folgende Entscheidungsfolge:

Wenn Sie grundlegende Seitenabläufe automatisch prüfen möchten, starten Sie mit Playwright WebKit. Dokumentieren Sie den Lauf als WebKit-Test.
Wenn die Aufgabe mehrere Browser-Engines verlangt, ergänzen Sie die in Ihrem Projekt eingerichteten Browser-Projekte und berichten Sie die Ergebnisse getrennt.
Wenn die Bewertung ausdrücklich Safari nennt, führen Sie die relevanten Schritte in Safari auf macOS aus. WebKit-Berichte oder WebKit-Screenshots ersetzen diesen Nachweis nicht.
Wenn eine Darstellung oder Funktion nur in Safari auffällig ist, reproduzieren Sie genau diese Stelle dort und halten Sie Browser, Betriebssystem, Seite, Bedienhandlung und sichtbares Ergebnis fest.
Wenn Sie keinen Zugang zu macOS haben, erledigen Sie zunächst die automatisierte Vorprüfung und klären Sie mit der Lehrkraft, welche konforme Umgebung die Abgabe akzeptiert.

Für eine saubere Safari-Dokumentation reichen pauschale Aussagen wie „getestet, funktioniert“ nicht. Halten Sie die geprüfte Seite, die konkrete Aktion und das beobachtete Ergebnis fest. Ergänzen Sie, ob Sie den Ablauf in Safari selbst oder nur in Playwright WebKit ausgeführt haben. Wenn ein Fehler auftritt, sichern Sie zusätzlich die Schritte, mit denen er reproduzierbar ist. So kann eine andere Person Ihre Aussage nachvollziehen, ohne dass Sie mehr behaupten, als Sie tatsächlich geprüft haben. <

Bedarf Ihrer Aufgabe	Passender Weg	Bewertung
Schnell prüfen, ob ein Frontend-Ablauf automatisiert funktioniert	Playwright mit WebKit	Sehr geeignet für eine frühe Vorprüfung
Unterschiede zwischen Engines eingrenzen	Derselbe Test in den konfigurierten Browser-Projekten	Geeignet, sofern Sie die Resultate getrennt dokumentieren
Safari ausdrücklich nachweisen	Safari-Anwendung auf macOS verwenden	Erforderlich, wenn die Abgabe echten Safari verlangt
Nur die visuelle Wirkung bewerten	Betroffene Seite und Ansicht in der verlangten Umgebung prüfen	Automatisierung allein reicht als Sichtprüfung nicht aus

Wenn Sie dafür einen Mac benötigen, wägen Sie Aufwand und Nutzungsdauer ab. Für wiederholte, dauerhafte Aufgaben kann ein eigener Mac sinnvoll sein; für eine einzelne Abgabe kann das eine unnötig hohe Anschaffung sein. Prüfen Sie außerdem, ob Ihre Schule eine zugelassene Mac-Umgebung bereitstellt. Wenn nicht, können Sie sich bei [MACGPU über verfügbare Mac-Umgebungen informieren](https://macgpu.com/de/index.html) und anhand der [Angaben zu den verfügbaren Mac-Angeboten](https://macgpu.com/de/m4-bestellen.html) prüfen, ob ein zeitweiliger Zugriff zu Ihrer Aufgabe passt. Klären Sie vorab, ob die konkrete Umgebung Safari enthält und für Ihre Abgabe zugelassen ist.

Dokumentieren Sie die Prüfung ohne Übertreibung

Eine gute Abgabe trennt Testmethode und Ergebnis. Schreiben Sie beispielsweise: „Der Ablauf wurde automatisiert mit Playwright im WebKit-Projekt geprüft. Safari wurde nicht separat geöffnet.“ Wenn Sie zusätzlich Safari genutzt haben, ergänzen Sie genau den geprüften Ablauf und die verwendete Umgebung. So ist klar, was Ihre Ergebnisse belegen und wo die Prüfung endet.

Ihre Notizen können knapp bleiben, sollten aber mindestens diese Fragen beantworten:

Welche Seite oder Funktion haben Sie geprüft?
Welche Bedienhandlung hat der Test ausgeführt?
Welches Browser-Projekt oder welcher Browser kam zum Einsatz?
Was war das erwartete Ergebnis und was wurde tatsächlich beobachtet?
Ist ein Fehler reproduzierbar, und falls ja, unter welchen Schritten?

Diese Angaben helfen auch dann, wenn ein Test zunächst fehlschlägt. Statt „Safari ist kaputt“ können Sie festhalten: „Der WebKit-Test findet nach dem Öffnen des Menüs den erwarteten Link nicht; die Locator-Auswahl wird geprüft.“ Wenn Sie den Ablauf anschließend in echtem Safari nachvollziehen, ergänzen Sie das Ergebnis als separate Beobachtung.

Für Ihr Frontend-Projekt ist Playwright WebKit ein guter erster Filter: Sie können unter Windows automatisierte Abläufe prüfen und Fehler gezielt eingrenzen. Es ist jedoch kein Ersatz für Safari, sobald Ihre Kursanforderung eine echte Safari-Prüfung verlangt. Wenn lokale Testläufe, Schulrechner oder eine vorhandene Mac-Umgebung diese Abnahme nicht ermöglichen, prüfen Sie, ob eine zeitweise macOS-Umgebung von MACGPU für Ihren konkreten Safari-Nachweis geeignet ist; bei langfristiger Nutzung oder besonderen Geräteanforderungen kann ein eigener Mac die bessere Wahl sein.