Stand der Testautomatisierung 2026: Playwright vs. Cypress

Robert Dey 5. Februar 2026

Zwei Frameworks dominieren die Web-Testautomatisierung in 2026: Cypress und Playwright. Jedes verfolgt einen grundlegend anderen Architekturansatz, und das Verständnis dieser Unterschiede ist entscheidend für die Wahl des richtigen Tools für Ihr Team.

Cypress führt Tests direkt im Browser aus und bietet eine exzellente Developer Experience sowie visuelles Debugging. Playwright steuert den Browser extern über Protokolle und bietet bessere Performance sowie Cross-Browser-Support. Beide haben sich im letzten Jahr erheblich weiterentwickelt, wobei KI-Features zu einem wichtigen Unterscheidungsmerkmal geworden sind.

Aktuelle Adoptionsdaten zeigen einen Wandel: Teams, die zu Playwright migrieren, berichten von CI/CD-Build-Zeit-Reduktionen von bis zu 70% und geringerer Test-Flakiness. Cypress hat mit KI-gesteuerten Testing-Features und Performance-Verbesserungen reagiert. Dieser Artikel vergleicht beide Frameworks hinsichtlich Architektur, Performance, Features und Anwendungsfällen, um Ihnen eine fundierte Entscheidung zu ermöglichen.

1. Wie wir hierher kamen: Ein kurzer Rückblick

Das Verständnis der Evolution der Testautomatisierung hilft zu erklären, warum Cypress und Playwright existieren und welche Probleme sie lösen.

1.1 Die Selenium-Ära

Über ein Jahrzehnt lang war Selenium der Standard für Browser-Automatisierung. Es verwendete das WebDriver-Protokoll, um Befehle per HTTP an Browser-Treiber zu senden. Diese Architektur funktionierte browserübergreifend, führte aber zu Latenzproblemen. Moderne JavaScript-Frameworks (React, Angular, Vue) änderten oft den Zustand schneller, als WebDriver mithalten konnte, was zu instabilen Tests und der gefürchteten “StaleElementReferenceException” führte.

1.2 Wie Cypress das Spiel veränderte

Cypress verfolgte einen anderen Ansatz: den Testcode direkt im Browser ausführen. Durch die Ausführung in derselben Run-Loop wie die Anwendung eliminierte Cypress Netzwerk-Latenz und konnte direkt auf DOM, Window-Objekt und Anwendungsstatus zugreifen. Dies löste viele Flakiness-Probleme und führte “Time Travel”-Debugging ein. Entwickler konnten den exakten Anwendungsstatus bei jedem Testschritt sehen. Das Ergebnis war ein Testing-Tool, das Frontend-Entwickler tatsächlich gerne nutzten.

1.3 Playwrights Ansatz

Playwright, entwickelt vom Team hinter Googles Puppeteer, nutzt das Chrome DevTools Protocol (CDP) und ähnliche Protokolle für Firefox und WebKit. Statt im Browser zu laufen, kommuniziert Playwright extern über WebSockets. Dies gibt volle Kontrolle über die Browser-Instanz: Netzwerk-Traffic, mehrere Tabs und isolierte Browser-Kontexte - alles mit minimalem Overhead.

1.4 Aktuelle Adoption

Mitte 2024 übertraf Playwright Cypress erstmals bei den wöchentlichen NPM-Downloads. Dieser Wandel spiegelt die wachsende Nachfrage nach Skalierbarkeit und Cross-Browser-Support wider. Cypress behält jedoch eine große Nutzerbasis und ein starkes Ökosystem, insbesondere für Component Testing in React- und Vue-Projekten.

2. Architektur: Der grundlegende Unterschied

Der architektonische Unterschied zwischen Cypress und Playwright beeinflusst jeden Aspekt ihres Verhaltens - von der Performance bis zu den Szenarien, die sie bewältigen können.

2.1 Cypress: In-Process-Modell

Cypress führt seinen Testcode im Browser neben Ihrer Anwendung aus.

• Proxy-basiertes Networking: Cypress fängt alle Netzwerkanfragen über einen Proxy-Server ab. Dies ermöglicht leistungsstarkes Request-Mocking, kann aber Probleme mit Unternehmens-Firewalls und komplexen Authentifizierungsflows (NTLM, SSO-Redirects) verursachen.
• Single-Tab-Limitation: Da Tests innerhalb des Browser-Tabs laufen, ist Cypress an das Sicherheitsmodell des Browsers gebunden. Multi-Tab- und Multi-Window-Szenarien erfordern Workarounds, die das reale Nutzerverhalten nicht vollständig replizieren.
• Cross-Origin-Einschränkungen: Die Same-Origin-Policy des Browsers betrifft Cypress. Das Testen von Flows über Domains hinweg (z.B. OAuth-Redirects) erfordert die Verwendung von cy.origin(), was Komplexität hinzufügt.

2.2 Playwright: Out-of-Process-Modell

Playwright steuert den Browser extern über WebSocket-Verbindungen.

• Direkter Protokollzugriff: Playwright kommuniziert direkt mit der Browser-Engine. Selbst wenn das JavaScript Ihrer Anwendung einfriert, läuft das Testskript weiter. Diese Trennung verbessert die Stabilität.
• Browser-Kontexte: Playwright kann isolierte “Kontexte” (ähnlich Inkognito-Fenstern) innerhalb eines einzelnen Browser-Prozesses erstellen. Jeder Kontext hat eigene Cookies und Cache. Dies ermöglicht das Aufsetzen hunderter isolierter Testumgebungen in Millisekunden - die Grundlage für Playwrights Parallelisierung.
• Auto-Wait: Vor der Interaktion mit Elementen prüft Playwright automatisch: Ist es im DOM? Sichtbar? Stabil? Nicht verdeckt? Dies geschieht auf Protokollebene und eliminiert die meisten expliziten Waits.

2.3 Vergleichsübersicht

3. Aktuelle Entwicklungen (2025-2026)

Beide Frameworks haben sich im letzten Jahr erheblich weiterentwickelt, wobei KI-Integration ein Hauptfokus war.

3.1 Playwright-Updates

Microsoft hat Playwrights Fähigkeiten kontinuierlich erweitert:

• Model Context Protocol (MCP): Ende 2025 wurde MCP-Support eingeführt, der KI-Agenten ermöglicht, mit Playwright zu interagieren. Tools wie Claude oder GitHub Copilot können nun den Browser steuern, Tests planen, Code generieren und sich selbst heilen, wenn sich die UI ändert.
• UI-Mode-Verbesserungen: Playwrights UI-Mode beinhaltet nun einen Watch-Mode mit sofortigem Feedback, Console-Logs und Netzwerk-Bodies im Trace-Viewer, was das Debuggen fehlgeschlagener CI-Runs erleichtert.
• Component Testing: Erweiterte Unterstützung für React-, Vue- und Svelte-Component-Testing in einem echten Browser-Kontext.

3.2 Cypress-Updates

Cypress hat sich auf Benutzerfreundlichkeit und KI-Features konzentriert:

• cy.prompt(): Auf der CypressConf 2025 angekündigt, ermöglicht dieses Feature das Schreiben von Testanweisungen in einfachem Englisch (z.B. cy.prompt(['click the login button', 'type "user" in name'])). Die KI interpretiert das DOM und führt Aktionen aus, mit Self-Healing-Fähigkeiten, wenn sich Element-IDs ändern.
• Performance-Verbesserungen: Version 15.8.0 (Dezember 2025) führte experimentalFastVisibility ein, um Beschwerden über langsame Sichtbarkeitsprüfungen in großen Test-Suites zu adressieren.
• Accessibility Testing: Natives Accessibility-Testing mit “UI Coverage”-Reports, die WCAG-Compliance über getestete Bereiche zeigen.

4. Performance und Skalierbarkeit

Die Testausführungsgeschwindigkeit beeinflusst direkt die Entwicklerproduktivität. Langsame Tests bedeuten langsame Feedback-Loops und seltenere Releases.

4.1 Benchmark-Ergebnisse

Unabhängige Benchmarks zeigen konsistent Playwright als die schnellere Option:

• Lingvano: Berichtete eine 70% Reduktion der CI-Ausführungszeit nach der Migration von Cypress zu Playwright. Build-Zeiten fielen von 6:38 auf 3:43, lokale Runs von ~90 Sekunden auf 25 Sekunden.
• Checkly: Fand Playwright etwa 23% schneller in der reinen Ausführungsgeschwindigkeit für vergleichbare Tests.

Cypress führt Tests standardmäßig seriell aus. Parallele Ausführung erfordert Cypress Cloud (kostenpflichtig) oder Workarounds wie cypress-split. Playwright unterstützt Sharding out-of-the-box (npx playwright test --shard=1/4).

Playwright verwendet Browser-Prozesse mit leichtgewichtigen Kontexten wieder und verbraucht weniger RAM als Cypress (das separate Prozesse spawnt). Dies erlaubt mehr Tests pro CI-Node.

Teams berichten von etwa 15% Reduktion bei instabilen Tests nach dem Wechsel zu Playwright. Die WebSocket-Architektur handhabt schnelle DOM-Updates zuverlässiger als Cypress’ loop-basierter Ansatz.

5. Migrationstendenzen

Viele Teams migrieren von Cypress zu Playwright, insbesondere für großskalige E2E-Suites. Hier sind die treibenden Faktoren dieser Entscheidungen.

5.1 Häufige Gründe für den Wechsel

Basierend auf Community-Feedback von Reddit und QA-Foren:

1. Safari/WebKit-Support: Cypress’ WebKit-Support bleibt experimentell. Playwright bündelt einen stabilen WebKit-Build, der Safari-Verhalten nachbildet, was für mobile-first B2C-Anwendungen wichtig ist.
2. iFrames und Multi-Tab-Flows: Anwendungen mit Payment-Gateways in iFrames oder OAuth-Popups sind in Playwright einfacher zu testen. Während Cypress cy.origin() hat, sind Playwrights frameLocator und Kontext-Handling unkomplizierter.
3. Preismodell: Features wie Parallelisierung und Test-Replay erfordern Cypress Cloud (kostenpflichtig). Playwright enthält HTML-Reporter, Trace-Viewer und Sharding kostenlos.

5.2 Migrationserfahrungen

JetBase migrierte 148 E2E-Tests mit GitHub Copilot, um Syntax-Übersetzung zu automatisieren (cy.get('.btn').click() zu await page.locator('.btn').click()). KI-Tools reduzieren den Migrationsaufwand erheblich.

Teams berichten, dass Playwrights async/await-Syntax für Programmierer einfacher zu verstehen ist als Cypress’ verkettete Syntax. Für Nicht-Programmierer ist jedoch das Gegenteil der Fall. Dies kann ein Reibungspunkt für manuelle Tester sein, die zur Automatisierung übergehen.

6. Feature-Vergleich

6.1 Selector-Strategien

Playwright fördert nutzerzentrierte Locators (getByRole, getByText, getByLabel), die mit Accessibility-Standards übereinstimmen. Shadow-DOM-Piercing funktioniert standardmäßig.

Cypress verwendet traditionell CSS-Selektoren oder data-cy-Attribute. Rollenbasierte Queries sind über cypress-testing-library verfügbar, sind aber nicht der Standard. Shadow DOM erfordert explizite Konfiguration.

6.2 Netzwerkkontrolle und API-Testing

Cypress glänzt beim Netzwerk-Stubbing über cy.intercept. Die Proxy-Architektur macht es einfach, Header zu modifizieren, Antworten zu verzögern oder benutzerdefinierte Daten zurückzugeben.

Playwright bietet page.route() für Interception sowie APIRequestContext für direkte HTTP-Requests. Dies ermöglicht Hybrid-Testing: Ein Auth-Token per API abrufen, in den Browser-Kontext injizieren und repetitive UI-Login-Flows überspringen.

6.3 Debugging

Cypress: Der “Time Travel”-Debugger zeigt DOM-Snapshots bei jedem Schritt, integriert mit Browser-DevTools. Exzellent für lokale Entwicklung und CSS-Debugging.

Playwright: Der Trace-Viewer zeichnet Screenshots, DOM-Snapshots, Netzwerk-HAR-Dateien und Console-Logs auf. Besser zum Debuggen instabiler Tests, die nur in CI fehlschlagen. Man kann die Ausführung offline durchgehen.

6.4 Component Testing

Cypress führt beim Component Testing. Sein Component-Runner mountet Komponenten im Browser mit sofortigem visuellem Feedback.

Playwright hat experimentelles Component Testing für React, Vue und Svelte. Neueres und kleineres Ökosystem, aber praktisch für Teams, die bereits Playwright für E2E nutzen.

7. KI-Integration

Beide Frameworks haben KI-Fähigkeiten hinzugefügt, aber mit unterschiedlichen Ansätzen. Für einen tieferen Einblick in die technischen Herausforderungen KI-gestützter Testgenerierung siehe unseren Artikel über E2E-Tests mit KI.

7.1 Cypress cy.prompt()

Cypress fokussiert sich darauf, die Einstiegshürde zu senken. Mit cy.prompt() beschreiben Tester Aktionen Schritt für Schritt in einfachem Englisch, und die KI führt sie aus.

• Vorteile: Ermöglicht schnellere Testerstellung und ist weniger anfällig für Selektor-Änderungen
• Nachteile: Black-Box-Ausführung kann schwerer zu debuggen sein; erfordert Cloud-Verbindung während der Testausführung für LLM-Verarbeitung

7.2 Playwright MCP

Playwright bietet Tooling für bestehende KI-Agenten. Das Model Context Protocol (MCP) erlaubt KI-Tools wie Claude oder benutzerdefinierten Agenten, den Browser zu steuern.

• Vorteile: Ermöglicht das Bauen benutzerdefinierter Agenten, die lokal laufen und Tests selbst heilen
• Nachteile: Komplexeres Setup im Vergleich zu cy.prompt()‘s Out-of-the-Box-Erfahrung

Suchen Sie nach dem Besten aus beiden Welten?

Wir entwickeln kiteto – ein KI-gestütztes Tool, das beide Ansätze kombiniert: Es generiert automatisch den richtigen nächsten Testschritt (wie cy.prompt), nutzt aber den Browser, um Playwright-Tests als Code zu erzeugen. Das Ergebnis: Stabile Tests, die bei der Ausführung nicht von LLMs oder Cloud-Anbindungen abhängig sind.

8. Markt und Community

8.1 Adoptionstrends

Playwrights NPM-Downloads übertrafen Cypress im Juni 2024. Wachstumsdaten deuten darauf hin, dass Playwright zur Standardwahl für neue Projekte wird, während Cypress eine große installierte Basis behält.

8.2 Geschäftsmodell-Überlegungen

Playwright: Open-Source, unterstützt von Microsoft, keine direkte Monetarisierung (es unterstützt Azure-Adoption)

Cypress: VC-finanziertes Unternehmen, das über Cypress Cloud monetarisiert. Einige Nutzer äußern Bedenken über Features, die hinter bezahlten Tiers gesperrt sind.

8.3 Arbeitsmarkt

Stellenausschreibungen für “Playwright”-Kenntnisse haben zugenommen, oft gepaart mit TypeScript und CI/CD-Erfahrung. Cypress bleibt häufig in Frontend-Engineer-Rollen. Das allgemeine Muster: Cypress für Frontend-Entwickler, Playwright für Software- und QA-Engineers.

9. Welches Framework sollten Sie wählen?

Die richtige Wahl hängt von Ihrem Team und Anwendungsfall ab. Für einen breiteren Überblick über Testing-Tools jenseits von E2E-Frameworks siehe unseren Software Testing Tools Guide.

9.1 Entscheidungsleitfaden

9.2 Hybrid-Ansatz

Viele Teams nutzen beide: Cypress für Component Testing (ausgeführt von Entwicklern im Frontend-Repo) und Playwright für E2E-Testing (ausgeführt von QA in der Deployment-Pipeline). Dies kombiniert Cypress’ Developer Experience mit Playwrights Zuverlässigkeit im großen Maßstab.

10. Fazit

Playwright und Cypress repräsentieren zwei unterschiedliche Philosophien der Testautomatisierung.

Cypress glänzt bei der Developer Experience. Seine In-Browser-Architektur bietet visuelles Debugging und sofortiges Feedback, das Frontend-Entwickler schätzen.

Playwright glänzt bei Skalierung und Zuverlässigkeit. Seine Out-of-Process-Architektur handhabt komplexe Szenarien (Multi-Tab, Cross-Domain, iFrames) eleganter, läuft schneller in CI und beinhaltet Parallelisierung kostenlos.

Unsere Empfehlung: Nutzen Sie Playwright für E2E-System-Testing, wo Zuverlässigkeit und Geschwindigkeit zählen. Nutzen Sie Cypress, wo es glänzt: Component Testing und Frontend-Developer-Workflows.

Häufig gestellte Fragen

1. Warum ist Playwright schneller als Cypress in CI/CD?

Playwright nutzt Browser-Kontexte, leichtgewichtige, isolierte Umgebungen, die in Millisekunden innerhalb eines einzelnen Browser-Prozesses aufgesetzt werden. Dies ermöglicht native parallele Testausführung mit minimalem Speicher-Overhead. Cypress führt Tests standardmäßig seriell aus und spawnt schwerere Prozesse. Benchmarks zeigen, dass Playwright CI-Build-Zeiten um bis zu 70% reduziert.

2. Kann ich KI nutzen, um Cypress-Tests zu Playwright zu migrieren?

Ja. Tools wie kiteto können einen Großteil der Übersetzung automatisieren. Teams berichten, hunderte Tests in Tagen zu migrieren, wobei KI die Boilerplate-Konvertierung übernimmt, während Engineers sich auf komplexe Logik konzentrieren.

3. Unterstützt Cypress Safari und Multi-Tab-Testing?

Cypress hat experimentellen WebKit-Support, aber er ist weniger stabil als Playwrights Implementierung. Multi-Tab-Testing erfordert in Cypress Workarounds aufgrund seiner In-Browser-Architektur. Playwright unterstützt mehrere Tabs und Fenster nativ.

4. Was ist der Unterschied zwischen cy.prompt() und Playwright MCP?

Playwright MCP (Model Context Protocol) ist Tooling, das KI-Agenten ermöglicht, den Browser programmatisch zu steuern. cy.prompt() ist ein Cypress-Feature zum Schreiben einzelner Testbefehle in einfachem Englisch. Wenn Sie Ihre gesamten Testfälle in einfachem Englisch schreiben möchten, sollten Sie sich kiteto ansehen.

5. Ist Playwright für kommerzielle Nutzung kostenlos?

Ja. Playwright ist vollständig Open-Source (Apache 2.0) mit allen Features kostenlos, einschließlich Parallelisierung, Trace-Viewing und Reporting. Cypress’ Test-Runner ist ebenfalls kostenlos (MIT), aber erweiterte Features wie Parallelisierung und Test-Replay erfordern das kostenpflichtige Cypress-Cloud-Abonnement.