Playwright oder Cypress: Cypress koppelt Parallelität an die Cloud

Cypress koppelt seine integrierte Verteilung von Tests über mehrere CI-Maschinen an aufgezeichnete Läufe in Cypress Cloud: Die CI-Dokumentation von Cypress verlangt dafür eine Aufzeichnung mit --record und die Ausführung mit --parallel. Ein gewöhnlicher Cypress-Lauf benötigt keine Cloud. Teams können Specs auch selbst auf getrennte Jobs verteilen; dann übernimmt ihre Pipeline die Zuweisung und Auswertung.

Playwright Test führt Testdateien bereits auf einem Rechner parallel in getrennten Workern aus und kann eine Suite per Sharding auf CI-Jobs aufteilen, wie die Playwright-Dokumentation zur Parallelität beschreibt. Für eine wachsende Suite mit mehreren Runnern ist das ein Vorteil, wenn das Team die CI-Ausführung selbst steuern will. Bei einer kurzen bestehenden Cypress-Suite kann dagegen der Aufwand einer Migration größer sein als der Nutzen zusätzlicher Parallelität.

Parallelität: Worker und CI-Maschinen getrennt betrachten

Playwright verteilt standardmäßig Testdateien auf Worker-Prozesse. Innerhalb einer Datei laufen Tests zunächst nacheinander; ihre parallele Ausführung muss eigens konfiguriert werden. Die Zahl der Worker lässt sich begrenzen, damit der Runner nicht mehr Browserprozesse startet, als seine Ressourcen tragen. Ein schnellerer lokaler Lauf ist deshalb keine feste Eigenschaft des Frameworks: Er hängt auch von der Dateistruktur und der verfügbaren Hardware ab.

Sharding verteilt eine Suite auf mehrere CI-Jobs. Das Team muss diese Jobs bereitstellen und ihre Ergebnisse einsammeln; die Aufteilung ersetzt keine CI-Infrastruktur. Bei Cypress übernimmt Cypress Cloud die Zuweisung von Specs an verfügbare Maschinen und gleicht deren Last anhand früherer Laufzeiten aus. Ohne diese Orchestrierung lassen sich getrennte Jobs mit jeweils ausgewählten Specs starten, doch Änderungen an der Suite können eine manuelle Aufteilung aus dem Gleichgewicht bringen.

Für die Kostenfrage zählen Laufzeit und belegte Runner-Zeit gemeinsam. Zusätzliche Maschinen können die Wartezeit bis zum Testergebnis senken, während gleichzeitig mehr Rechenkapazität belegt wird. Bei Cypress kommt die Entscheidung hinzu, ob die Funktionen und der gegebenenfalls nötige Tarif von Cypress Cloud zur Pipeline passen. Eine einzelne schnelle Spec sagt wenig über diese Gesamtrechnung aus.

Browser: WebKit trennt die Anforderungen

Playwright kann Tests in Chromium, Firefox und WebKit ausführen und bietet dafür konfigurierbare Browserprojekte. Auch Google Chrome und Microsoft Edge lassen sich gezielt verwenden, wie die Playwright-Browserdokumentation erläutert. Mehr Projekte bedeuten allerdings mehr Testausführungen: Eine breite Browsermatrix benötigt entweder zusätzliche Zeit oder weitere parallele Kapazität in der CI.

Cypress unterstützt Browser der Chrome-Familie und Firefox. WebKit steht ebenfalls zur Verfügung, wird in der Cypress-Browserliste aber als experimentell geführt. Dafür müssen die experimentelle Unterstützung aktiviert und das Paket playwright-webkit installiert werden. Zu den dokumentierten Einschränkungen gehört, dass Test Replay mit WebKit nicht unterstützt wird.

Für Teams mit verbindlichen WebKit-Tests ist dieser Status ein Auswahlkriterium. Dabei sollte WebKit nicht mit Safari gleichgesetzt werden: Auch Playwright verwendet einen eigenen WebKit-Build und startet nicht die Safari-Version von Apple. Wenn die Anwendung vor allem in Chrome und Firefox geprüft werden muss, wiegt der Unterschied weniger schwer als Laufzeit, Diagnose und Pflege der vorhandenen Tests.

Was die Angular-Messung tatsächlich zeigt

Die veröffentlichte Angular-Untersuchung wiederholte fünf E2E-Szenarien für jedes Framework und jede Browserumgebung jeweils 50-mal auf einem lokalen Windows-10-Rechner; im ersten Szenario betrug die mittlere Laufzeit 10,33 Sekunden mit Playwright und 21,96 Sekunden mit Cypress. In allen untersuchten Szenarien lagen die mittleren Zeiten von Playwright niedriger. Auch die Verteilung der gemessenen Laufzeiten war insgesamt enger.

Beim Ressourcenbedarf zeigte sich ein weiterer Unterschied: Playwright benötigte in diesem Aufbau weniger Arbeitsspeicher, beanspruchte die CPU jedoch etwas stärker. Das ist für begrenzte Runner-Ressourcen interessant, liefert aber noch keine Rechnung für eine verteilte CI-Pipeline. Die Messung lief lokal mit einer bestimmten Angular-Anwendung, definierten Abläufen und kontrollierten Testdaten. Sie erfasst weder die Koordination vieler Jobs noch die Kosten eines Cloud-Dienstes.

Die Autoren verglichen auch den Umfang der Testdateien. Playwright brauchte in den meisten Szenarien weniger Codezeilen; beim Ablauf mit zwei BrowserContexts war die Playwright-Datei länger als die Cypress-Variante. Codeumfang ist allerdings nur ein Teil der Wartbarkeit. In einer bestehenden Suite bestimmen auch gemeinsam genutzte Hilfsfunktionen, Selektoren und das Zurücksetzen von Backend-Daten, wie aufwendig Änderungen oder eine Migration werden.

Isolation und Fehlersuche beeinflussen den Betrieb

Playwright trennt Worker-Prozesse und BrowserContexts. Damit bleiben Browserzustände wie Cookies und Speicher zwischen parallelen Ausführungen isoliert. Cypress setzt bei aktivierter Testisolation vor Tests ebenfalls Browserzustand zurück. Beide Mechanismen enden jedoch am Browser: Ändern gleichzeitig laufende Tests denselben Nutzer oder Datensatz im Backend, können sie sich weiterhin gegenseitig stören.

Wer die Worker-Zahl erhöht, muss daher auch Testdaten und Konten für parallele Abläufe einplanen. Eindeutige Datensätze oder ein verlässlicher Reset verhindern Konflikte, die sonst wie instabile Framework-Tests aussehen. Gerade bei datenintensiven E2E-Suiten kann dieser Aufwand den Gewinn durch zusätzliche Runner begrenzen.

Für CI-Fehler bieten beide Werkzeuge Diagnosewege mit unterschiedlichen Voraussetzungen. Playwright kann Traces erzeugen, die Aktionen und Browserzustände für die spätere Analyse festhalten; die Pipeline muss diese Artefakte aufbewahren. Cypress Cloud bietet für aufgezeichnete Läufe unter anderem Test Replay mit Einblick in DOM, Netzwerkanfragen und Konsolenmeldungen. Wer den Dienst bereits nutzt, sollte diesen Diagnosewert zusammen mit der Verteilung bewerten, statt nur die Laufzeit zu vergleichen.

Welche Wahl zur eigenen Pipeline passt

Für eine neue oder stark wachsende Suite spricht Playwright besonders dann, wenn lokale Worker, selbst verwaltete CI-Jobs und eine reguläre WebKit-Abdeckung gefragt sind. Das Team behält die Verteilung in seiner Pipeline, muss aber Runner, Browserinstallationen und Ergebnisartefakte passend einrichten. Die technische Möglichkeit zum Sharding nimmt ihm diese Betriebsarbeit nicht ab.

Cypress kann die vernünftigere Wahl bleiben, wenn Tests, Hilfsfunktionen und Fehlersuche bereits zuverlässig funktionieren und die Suite innerhalb der gewünschten Feedbackzeit läuft. Bei größerem Verteilungsbedarf entscheidet sich, ob Cypress Cloud für das Team auch wegen seiner Orchestrierung und Diagnosefunktionen sinnvoll ist. Ohne Cloud lässt sich Arbeit auf CI-Jobs verteilen, aber die eigene Pipeline muss die Specs und Resultate koordinieren.

Vor einem Frameworkwechsel lohnt ein Vergleich repräsentativer Abläufe in der vorgesehenen Browsermatrix: Entscheidend sind die gesamte Wartezeit bis zum CI-Ergebnis, belegte Runner-Kapazität, reproduzierbare Fehler und der Aufwand für Testdaten. Bestehende Tests sollten dabei mitgerechnet werden, weil ihre Migration Zeit kostet. Die Angular-Messung gibt einen konkreten Hinweis auf Laufzeit und Ressourcenbedarf; die passende Wahl ergibt sich aus der Architektur und dem Zustand der eigenen Suite.

Lesen Sie auch:

• Claude oder Gemini für lange Dokumente: Eine Million Token reichen nicht
• Eine EU-Cloud ist nicht automatisch souverän – 48 Kriterien machen den Unterschied
• Nutzungsrechte verteuern Creator-Deals – die Laufzeit wird zum Preistreiber