Von Cypress zu Playwright

Die Migration von Cypress nach Playwright bezeichnet den strukturierten Wechsel eines Testautomatisierungs-Frameworks bei laufendem Betrieb. Auslöser sind typischerweise technische Grenzen wie fehlende iFrame-Unterstützung, Scroll-Probleme und Abhängigkeiten von Drittanbieter-Parallelisierungsdiensten. Der Umstieg gelingt am besten über einen Hackathon zur Framework-Evaluierung, eine klare Priorisierung kritischer Testpfade und schrittweise Migration parallel zum Tagesgeschäft.

Das Wichtigste in Kürze

• Ein Hackathon, bei dem sieben Tools an echten Testszenarien der eigenen Website erprobt werden, liefert mehr Entscheidungssicherheit als jede rein statische Marktrecherche oder Herstellerdemo.
• Cypress blockiert ab Version 13 die Nutzung des Drittanbieter-Parallelisierungsdienstes “Currents”, was Teams, die nicht die teure Cypress-Cloud buchen wollen, faktisch zum Framework-Wechsel zwingt.
• Der Übergang von Cypress zu Playwright dauert bei Displate trotz klarer Priorisierung länger als ein Jahr, weil das QA-Team parallel seinen regulären Testbetrieb aufrechterhalten muss.
• Wer Cypress-Code eins zu eins in Playwright übersetzt, kämpft gegen das Framework statt mit ihm, weil beide Tools grundlegend unterschiedliche Ansätze zur Sitzungs- und Datenverwaltung verfolgen.
• Tests, die dauerhaft gegen die Produktionsumgebung laufen, verfälschen Analysedaten, wenn Cookies und Tracking-Parameter nicht gezielt deaktiviert werden.

Warum Cypress nach Jahren im Einsatz an Grenzen stößt

Cypress lässt sich schnell erlernen, zwingt Teams aber in eine sehr eigene Art, Tests zu schreiben. Das Framework bringt eine domänenspezifische Sprache mit, eine eigene Logik für Assertions und feste Vorstellungen davon, was ein Test prüfen sollte. Wer davon abweicht, arbeitet gegen das Werkzeug statt mit ihm.

Genau das wurde bei einem E-Commerce-Anbieter mit eigener Fabrik zum Problem. Hinter dem sichtbaren Shop liegen viele eigene Admin-Funktionen: Verwaltung von Kunstwerken, Urheberrechte, Koordination mit Künstlern. Diese Mischung aus Standard-Shop und individuellem Code passte schlecht zu den Annahmen, die Cypress über einen typischen Testfall trifft.

Ein wiederkehrender Reibungspunkt waren iFrames. Drittanbieter wie Zahlungsdienstleister werden oft als iFrame eingebunden, und Cypress kommt damit nur über zusätzliche Plugins zurecht. Solche Plugins lösen das Problem kurzfristig, müssen aber bei jedem Versionssprung neu auf Kompatibilität geprüft werden.

Auch Screenshots im Fehlerfall verursachten Aufwand. Bei einer sehr langen Seite landete der Vollbild-Screenshot nicht zuverlässig an der Stelle, an der der Test fehlschlug. Stattdessen zeigte er mehrfach den Header. Workaround folgte auf Workaround, ohne dass eine saubere Lösung entstand.

Die Parallelisierung von Cypress ist ein Geschäftsmodell, kein Feature

Cypress verlangt für komfortable Parallelisierung in der Cloud Geld, und das wurde zum Auslöser für den Wechsel. Das Framework selbst ist kostenlos, eine lokale Parallelisierung lässt sich über eigene Plugins bauen. Bequem wird es erst über die kostenpflichtige Cypress Cloud oder über Drittanbieter.

Das Team nutzte einen solchen Drittanbieter, weil es mehr Nutzerplätze brauchte, nicht mehr Test-Runs. Cypress hätte dafür einen deutlich größeren Tarif mit vielen ungenutzten Runs verlangt, ohne flexibel auf die Situation einzugehen. Diese Kosten lagen über dem gesamten QA-Budget des Jahres.

Hinzu kam ein Konflikt zwischen Cypress und dem genutzten Drittanbieter, der so weit ging, dass neuere Cypress-Versionen sich mit dem Werkzeug nicht mehr kombinieren ließen. Das Repository steckt deshalb bis heute auf einer älteren Version fest, der letzten unterstützten. Für das Team war das ein Signal, das Cypress-Ökosystem ganz zu verlassen. Die Entscheidung fiel im September 2023.

Wie man ein Testautomatisierungs-Tool wirklich auswählt

Die belastbare Auswahl beginnt nicht mit dem Markt, sondern mit der eigenen Nutzung. Maciej Wyrodek und sein Team analysierten zuerst, wofür sie Cypress überhaupt einsetzten, was gut funktionierte und was nicht. Daraus entstand eine allgemeinere Frage: Wie wollen wir testen, und welche Eigenschaften muss ein Framework dafür mitbringen?

Aus dieser Klärung wurde eine Kriterienliste. In einer großen Bewertungstabelle bekamen die Tools Punkte, manche Kriterien wogen schwerer als andere. So blieben rund sieben Werkzeuge übrig, die in die nächste Runde gingen.

Die Marktrecherche selbst war ernüchternd. Zwischen 2019 und 2024 hatte sich an den verfügbaren Tools wenig getan. Das letzte größere Tool, das auftauchte, war Playwright, damals noch jung. Eine frühere Erwartung, dass Record-and-Play-Werkzeuge den Markt dominieren würden, hatte sich nicht erfüllt. Solche Tools existieren, sind aber stark eingeschränkt und passen nur bei sehr spezifischen Anforderungen in den Arbeitsablauf.

Der Hackathon: Proof of Concept statt Feature-Liste

Eine statische Bewertung reicht nicht, ein Tool muss am eigenen System beweisen, dass es trägt. Deshalb folgte auf die Tabelle ein praktischer Tag. QA-Engineers und einige Entwickler bauten mit den Kandidaten echte Proof-of-Concepts auf der eigenen Website.

Damit die Ergebnisse vergleichbar blieben, gab es eine feste Liste von zehn Testszenarien. Jeder versuchte, dieselben Fälle im jeweiligen Tool umzusetzen. So zeigte sich, wie viele Tests pro Werkzeug überhaupt entstehen und wie aufwändig der Weg dorthin war.

Die Schwächen wurden im Praxistest sofort sichtbar. Bei einem code-basierten Tool gelang es zwei erfahrenen Leuten an einem ganzen Tag nicht, auch nur einen lauffähigen Test zu erstellen. Die Dokumentation war nach einem größeren Update veraltet, Antworten fanden sich nur noch in den Issues des GitHub-Repositories. Ein Tool, dessen Nutzung sich nur über Support-Tickets erschließt, fiel damit aus.

Dann erklär deinem Chef mal, warum du dich nach all der Recherche immer noch für das Tool entscheidest, das von Anfang an die naheliegende Wahl war. Aber dann hast du den Beweis. Maciej Wyrodek

Wenn KI-Testgenerierung sechs Minuten bis zum Warenkorb braucht

Ein KI-gestütztes Tool erzeugte Tests aus natürlicher Sprache, lieferte aber unbrauchbare Pfade. Die Aufgabe lautete sinngemäß: gehe auf die Startseite, wähle das erste sichtbare Produkt, lege es in den Warenkorb, kaufe es. Bei tausenden Produkten auf der Startseite verlor sich die Automatisierung.

Statt direkt zum Produkt zu navigieren, klickte das Tool durch Menüs, von einer Kollektion in die nächste, dann auf eine Markenseite. Ein aufpoppendes Newsletter-Fenster schloss es nebenbei selbst. Erst nach sechs Minuten Klicken landete der Test auf einer Produktseite und legte etwas in den Warenkorb. Ein solches Szenario ist nicht wartbar.

Der Grund liegt in der Mechanik: Ein Sprachmodell generiert den Pfad neu, sobald man den Test erneut anstößt. Erst wenn ein erzeugter Pfad bestätigt und als Skript festgeschrieben wird, entsteht etwas Stabiles. Ohne diese Fixierung produziert dasselbe Tool bei jedem Lauf einen anderen Weg.

Warum Playwright den Vergleich klar gewann

Playwright lieferte im Praxistest die besten Ergebnisse und ließ die Alternativen deutlich hinter sich. Die einzigen beiden Teilnehmer, die alle zehn Szenarien umsetzten, arbeiteten beide mit Playwright. Einer nutzte dessen Aufzeichnungsfunktion, ein anderer kombinierte Playwright mit einer KI-gestützten IDE und brachte alle zehn Fälle im Rahmen des Hackathons zum stabilen Laufen.

Zur Einordnung gehört eine ehrliche Einschränkung. Die so erzeugten Tests waren noch nicht produktionsreif. Ohne sauberen Code hätte man bei jeder Änderung den ganzen Test neu aufnehmen müssen, ähnlich wie bei reinem Record-and-Play. Der Hackathon zeigte das Potenzial, nicht das fertige Ergebnis.

Trotz der vorhersehbaren Wahl war der Aufwand sinnvoll. Erst der Praxistest macht aus einer Vermutung einen belegten Entscheid, den man auch gegenüber dem Management vertreten kann.

Migration in Schichten: vom kritischen Pfad nach außen

Eine sinnvolle Migrationsreihenfolge orientiert sich am Geschäftswert der Tests, nicht an ihrer Reihenfolge im Repository. Das Team strukturierte seine End-to-End-Tests in mehreren Ebenen:

Den Anfang machten die Top 10. Diese Tests müssen am schnellsten laufen, sind selten die einfachsten und schneiden vertikal durch das gesamte System. Genau deshalb eignen sie sich als erster Prüfstein für das neue Framework.

Für laufende Cypress-Tests gilt eine pragmatische Regel. Bei kleinen Defekten wie einem geänderten Locator wird in Cypress repariert. Ändert sich die Logik eines Tests, wandert er nach Playwright. Neue Features bekommen ihre Tests ausschließlich in Playwright.

Session-Handling und Request-Interception unterscheiden sich stärker als erwartet

Frameworks behandeln Sessions, Cookies und Netzwerk-Requests nicht gleich, und das wird bei der Migration teuer. Beim Wechsel überraschte vor allem das unterschiedliche Session-Management. Die Website nutzt viele A/B-Tests sowie Daten in Local Storage, Session Storage, Cache und Cookies. Damit Tests verlässlich laufen, muss dieser Zustand sauber gesetzt werden.

Ein konkreter Grund dafür: Viele Tests laufen direkt in der Produktion. Deshalb müssen Analyse-Cookies deaktiviert werden, sonst tauchen Testläufe in den Auswertungen auf. In der Vergangenheit fiel intern bereits auf, dass eine im Test häufig verwendete Produktseite hohe Besucherzahlen ohne Käufe erzeugte, schlicht weil die Automatisierung sie hunderttausendfach ansteuerte.

Das Abfangen von API-Requests war in Cypress kompakter gelöst, in Playwright kostete dasselbe mehr Recherche. Was in Cypress ein Zweizeiler war, etwa das Mitlesen einer Autorisierungs-Anfrage, erforderte in Playwright das Durcharbeiten mehrerer Anleitungen.

Besonders unterschätzt wurde das Blockieren von Hosts. In Cypress genügte eine Option im Konfigurationsblock. In Playwright fehlt ein direktes Äquivalent, das Team musste die Request-Interception selbst bauen. Diese Anforderung stand nicht einmal auf der Kriterienliste, weil man stillschweigend annahm, ein Tool mit Request-Handling decke das mit ab.

Tests übersetzen ist nicht dasselbe wie Tests neu denken

Cypress-Code Zeile für Zeile nach Playwright zu portieren erzeugt schlechte Tests. Die ursprüngliche Vereinbarung lautete, die Logik zu übernehmen, aber nicht den Code eins zu eins. Unter Termindruck ging diese Regel verloren, und Cypress-Code wurde direkt in Playwright umgeschrieben. Maciej beschreibt das als Versuch, ein Quadrat zurück in einen Kreis zu verwandeln.

Das ist kein individuelles Versagen, sondern ein typischer Effekt von Druck. Die Frist rückt näher, das neue Tool ist noch nicht in Fleisch und Blut übergegangen, und der vertraute alte Code wird zur Krücke. Wer mitten in der Einarbeitung steht, greift auf bekannte Muster zurück, auch wenn sie im neuen Framework nicht passen.

Manche dieser Tests sind alt, einer ist älter als die Zugehörigkeit des heutigen QA-Leads im Unternehmen. Solche gewachsenen Tests verlangen beim Umzug eine bewusste Neukonzeption statt einer Übersetzung.

KI als Migrationshelfer: Potenzial mit offenem Wartbarkeitsrisiko

KI kann die Übersetzung von Cypress nach Playwright beschleunigen, die Wartbarkeit der Ergebnisse ist aber noch nicht gesichert. Ein Entwickler experimentierte mit einer KI-gestützten IDE und fütterte sie mit dem Cypress-Repository, der Playwright-Dokumentation und dem Auftrag, einen bestimmten Test in Playwright neu zu erzeugen.

Nach einigen Versuchen entstanden funktionierende Tests. In einer Live-Demo scheiterte derselbe Ablauf allerdings, was die typische Lücke zwischen Einzelerfolg und Reproduzierbarkeit zeigt. Das Verfahren ist vielversprechend, aber noch nicht verlässlich.

Der eigentliche Hebel liegt woanders. Wenn das gesamte Team lernt, die KI-IDE besser zu bedienen und präzisere Prompts zu schreiben, steigt die Geschwindigkeit beim Erstellen von Tests. Offen bleibt die zentrale Frage, ob die generierten Tests langfristig wartbar sind.

Frontend-Entwickler in die Testautomatisierung holen

Der Wechsel auf Playwright wird genutzt, um Tests stärker im Entwicklungsteam zu verankern. Schon während der Migration beteiligen sich Frontend-Entwickler an den Pull-Requests. Sobald die Top-10-Suite stabilisiert ist, sollen sie eigene Tests schreiben und pflegen.

Das passt zum Arbeitsmodell des QA-Teams. Es arbeitet nicht mit einem Tester pro Team, sondern wie ein Plattform-Team, das andere unterstützt, vergleichbar mit dem Aufbau eines DevOps-Teams. Die Entwickler testen ihre Features überwiegend selbst, das QA-Team liefert Methodik und löst schwierige Fälle, etwa wie sich eine neue Zahlungsmethode in einem bestimmten Markt prüfen lässt.

Daraus folgt eine realistische Sicht auf das Tempo. Über das Jahr hinweg bleibt nicht durchgehend Kapazität für die Migration, in manchen Monaten kaum. Eine rotierende Zuständigkeit verteilt die Automatisierungsarbeit, und die Reihenfolge richtet sich nach dem Backlog, für den bewusst etwas Kapazität reserviert wird.