Umstellung von Cypress auf Playwright

Die Migration von Testautomatisierungsframeworks bedeutet, dass eine komplette Ende-zu-Ende-Testsuite von einem Tool auf ein anderes umgestellt wird, während die tägliche Arbeit des Testens weiterläuft. In der Regel führen Teams einen strukturierten Hackathon durch, um die in Frage kommenden Tools anhand realer Testszenarien zu testen, bevor sie sich festlegen. Bei der Umstellung von Cypress auf Playwright treten häufig versteckte Lücken zutage: Sitzungsverwaltung, das Abfangen von Anfragen und das Verhalten bei Ganzseiten-Screenshots funktionieren in den beiden Frameworks unterschiedlich.

Das Wichtigste in Kürze

• Die Wahl des beliebtesten Frameworks für den falschen Kontext führt zu komplizierten Workarounds: Cypress war schlecht geeignet für iFrame-lastige Zahlungsströme, ganzseitige Screenshots und das spezielle Scrollverhalten von React.
• Die Bindung an den Anbieter bei der Parallelisierung hat die Beziehung zu Cypress beendet: Cypress blockierte Orchestrierungstools von Drittanbietern ab Version 13, so dass die Teams entweder ein Vielfaches ihres QA-Budgets für Cypress Cloud ausgeben mussten oder auf einer veralteten Version stehen blieben.
• Ein eintägiger praktischer Hackathon mit realen Testszenarien am tatsächlichen Produkt zeigt, dass die Tools schneller und zuverlässiger passen als jeder statische Funktionsvergleich oder jede Anbieterdemo.
• Die KI-gestützte Migration von Cypress zu Playwright ist vielversprechend, erfordert aber eine sorgfältige Eingabe von Repos und Dokumentationen in den Agenten, und die Ergebnisse müssen noch von Menschen überprüft werden, um eine langfristige Wartbarkeit zu gewährleisten.

Warum ein beliebtes Tool trotzdem falsch sein kann

Das beliebteste Tool für die Testautomatisierung ist nicht automatisch das richtige für deinen Kontext. Cypress ist schnell zu erlernen und weit verbreitet, aber es forciert eine bestimmte Art, Tests zu schreiben, die nicht zu jedem Projekt passt.

Cypress wird mit einer eigenwilligen, domänenspezifischen Sprache geliefert. Sie schreibt weitgehend vor, wie Assertions aussehen, was ein Test prüft und wie der Test aufgebaut ist. Wenn deine Bedürfnisse von diesem beabsichtigten Stil abweichen, schreibst du gegen das Framework an, statt mit ihm.

Plugins füllen viele der Lücken, und Cypress hat Tausende von ihnen. Die Kosten dafür zeigen sich erst später: Die Wartung der Plugins und ihre Kompatibilität mit anderen Cypress-Versionen wird zu einem eigenen Aufwand. Ein Werkzeug, das eine ganze Reihe von Plugins benötigt, um das zu tun, was du willst, ist ein Signal, das es wert ist, gelesen zu werden.

Maciej Wyrodek verweist auf ein konkretes Muster aus seiner Arbeit bei Displate. Die Art und Weise, wie das Team Tests schrieb, und die Anforderungen, die sie an diese Tests stellten, wichen immer wieder von dem ab, was Cypress standardmäßig bot. Diese Diskrepanz, die sich über viele Tests erstreckt, ist der eigentliche Grund, ein Framework zu überdenken, nicht ein einzelner ärgerlicher Fehler.

Die technischen Reibungen, die sich anhäufen

Einzelne technische Einschränkungen rechtfertigen für sich genommen selten eine Migration. Wenn sie sich im Laufe der Zeit auftürmen, schon.

Iframes von Drittanbietern sind ein bekannter wunden Punkt. Zahlungsströme finden oft innerhalb von iframes statt, und Cypress geht mit ihnen umständlich um. Ein Plugin macht es möglich, aber die Handhabung von Iframes bleibt anfällig.

Ganzseitige Screenshots bei Fehlerwirkung waren für eine lange Webseite sehr schmerzhaft. Wenn eine Assertion ein Element unterhalb des Falzes prüfte, zeigte die erfasste Fehlhandlung nicht immer die korrekte Scrollposition an. Ein dokumentiertes Problem mit bestimmten React-Konfigurationen wiederholte den Seitenkopf in einer Ganzseitenerfassung mehrmals, anstatt die Seite einmal zu rendern.

Für jedes dieser Probleme gab es einen Workaround. Das Problem ist die Form des Ergebnisses: Workarounds auf Workarounds aufgeschichtet. Wenn deine Testsuite auf diese Weise zusammengehalten wird, hat das Framework aufgehört, dem Team zu dienen.

Wie die Parallelisierung von Cypress zu einem Geschäftsproblem wurde

Der entscheidende Bruch war kommerziell, nicht technisch. Cypress verkauft die Parallelisierung als bezahlte Dienstleistung, was die Kalkulation für ein größeres Unternehmen verändert.

In der Selenium-Ära konnte man ein Selenium-Grid selbst hosten und seine eigene Parallelisierung betreiben oder Grid-Kapazitäten von Anbietern kaufen. Cypress hat einen anderen Weg eingeschlagen und ein Geschäft rund um parallele Läufe aufgebaut. Das Framework selbst ist kostenlos, aber die Skalierung der Testdurchführung führt zu einem kostenpflichtigen Hosting.

Displate nutzte Currents, eine Alternative zu Cypress Cloud von einem Drittanbieter. Für eine Organisation ihrer Größe war Cypress Cloud etwa 10 bis 20 Mal teurer als Currents, was daran lag, wie Cypress Benutzer und Läufe zusammenfasste. Das Team brauchte mehr Nutzer, nicht mehr Läufe, und Cypress war bei dieser Kombination nicht flexibel. Das Cypress Cloud-Paket, zu dem sie gedrängt wurden, hätte mehr als das gesamte QA-Budget für das Jahr verschlungen.

Die Beziehung verschlechterte sich daraufhin. Cypress blockierte die Möglichkeit, Currents ab Version 13 zu verwenden. Displate blieb bei Cypress Version 12, der letzten Version, die Currents unterstützt, und beschloss, das Cypress-Ökosystem zu verlassen.

Die Lektion lässt sich über einen einzelnen Anbieter hinaus verallgemeinern: Wenn ein Anbieter dich wie einen Gefangenen und nicht wie einen Verhandlungspartner behandelt, ist das schon ein Grund, den Ausstieg zu planen.

Warum eine Tool-Migration viel länger dauert als die Entscheidung

Die Entscheidung, ein Framework zu verlassen, ist schnell getroffen. Die Migration ist es nicht.

Displate beschloss im September 2023, Cypress zu verlassen. Der tatsächliche Umzug erstreckte sich über das folgende Jahr und darüber hinaus, weil das Team die ganze Zeit über mit der täglichen Arbeit des Testens beschäftigt ist. Die Pflege bestehender Tests und die Unterstützung der Entwicklung pausieren nicht, während du das Framework wechselst.

Eine Migration, die mit der regulären Auslieferung konkurriert, kann nicht von einem Tag auf den anderen stattfinden. Sie braucht reservierte Kapazitäten und einen realistischen Zeitplan, sonst geht sie schief. Betrachte die Umstellung als ein langfristiges Projekt mit eingefrorener Kapazität, nicht als Sprintziel, das du in ein arbeitsreiches Quartal einbaust.

Wie man Automatisierungswerkzeuge bewertet, ohne zu raten

Die Auswahl eines Frameworks beginnt damit, dass du dein aktuelles System verstehst, und nicht damit, dass du dem Marktführer hinterherläufst. Schau dir zuerst an, was du tatsächlich benutzt, was dir gefällt und was dir misslingt.

Ausgehend von dieser konkreten Liste kannst du dir die allgemeine Frage stellen: Was erwartest du von einem Ende-zu-Ende-Test-Framework, und wie sieht dein Testansatz aus? Setze das in Kriterien um, die du bewerten kannst. Displate hat eine Punktetabelle erstellt, in der einige Kriterien mehr Gewicht haben als andere, und so das Feld auf etwa sieben Tools eingegrenzt.

Statische Recherchen reichen nur bis zu einem gewissen Punkt. Demos und Dokumentationen sagen dir, was der Anbieter zu sehen wünscht, aber nicht, wie sich das Tool auf deiner eigenen Website verhält.

Der Markt selbst hat das Team überrascht. Vergleicht man die Landschaft von 2024 mit der von 2019, hat sich kaum etwas verändert. Der letzte große Neuzugang war Playwright zu Beginn der Pandemie. Die Welle von Aufzeichnungs- und Abspielprogrammen, die einst zu dominieren schien, blieb eine Nische, die nur dann nutzbar ist, wenn deine Bedürfnisse in ihre enge Form passen.

Warum ein praktischer Hackathon besser ist als eine Feature-Checkliste

Ein praktischer Proof of Concept zeigt, was eine Feature-Matrix nicht kann. Displate führte einen Hackathon mit Qualitätsingenieuren sowie interessierten Backend- und Frontend-Entwicklern durch und testete die in die engere Wahl gekommenen Tools anhand von zehn vorbereiteten Testfällen.

Die zehn festgelegten Szenarien dienten zwei Zwecken. Sie schufen eine gemeinsame Basis, so dass nicht jeder unterschiedliche Tests schreiben musste, und sie ließen das Team zählen, wie viele Testfälle jedes Tool tatsächlich bewältigen konnte.

Der Hackathon deckte Probleme auf, die kein Tabellenkalkulationsprogramm erkennen konnte. Ein programmiertes Tool konnte an einem ganzen Tag keinen einzigen funktionierenden Test erstellen, selbst wenn man die Dokumentation und die Schnellstartanleitung befolgte. Nach einem kürzlichen Update des Frameworks war die Dokumentation so veraltet, dass der einzige Weg nach vorne über GitHub Issues führte. Allein die Tatsache, dass man sich durch Support-Tickets wühlen musste, anstatt die Dokumentation zu lesen, war schon ein Ausschlusskriterium.

Hier ist das unangenehme Ergebnis. Nach all den Recherchen entschied sich das Team für Playwright, die beliebteste Option und der offensichtliche Kandidat von Anfang an. Der Unterschied ist, dass die Wahl nun auf Beweisen und nicht auf Vermutungen beruhte, und diese Beweise musst du deinem Management vorlegen.

Was die KI-Testerzeugung während der Evaluierung tatsächlich tat

KI-gesteuerte Testerzeugung sieht beeindruckend aus und ersetzt noch keine wartbare Testsuite. Ein evaluiertes Tool bot eine KI-Komponente an, die aus einer BDD-artigen Beschreibung einen Test generierte.

Ein Entwickler fügte die vorbereiteten Anweisungen ein: Gehe zur Homepage, wähle das erste Produkt aus, lege es in den Warenkorb und kaufe es. Das Tool scannte die Seite und improvisierte. Es wanderte durch Menüs und Kollektionsseiten, sprang auf eine Markenseite, verwarf ein Newsletter-Pop-up von sich aus und erreichte nach etwa sechs Minuten Klickzeit schließlich eine Produktseite und legte es in den Warenkorb.

Der Weg, den das Tool nahm, entsprach in keiner Weise dem vorbereiteten Szenario. Unter der Haube hat ein KI-Agent zuerst einen Pfad generiert und ihn nach der Freigabe als Skript geschrieben. Wird die gleiche Eingabeaufforderung später noch einmal ausgeführt, würde sie wahrscheinlich einen völlig anderen Pfad ergeben, weil das Sprachmodell die Route jedes Mal neu generiert.

Dieser Nicht-Determinismus ist der Haken. Einem Test, der bei jedem Durchlauf einen anderen Weg einschlägt, kann man nur schwer vertrauen und er ist noch schwerer zu warten.

Wie Playwright im selben Hackathon abgeschnitten hat

Playwright erzielte die besten Ergebnisse im Kopf-an-Kopf-Rennen. Ein Entwickler, der Cursor zusammen mit dem Aufnahmeinspektor von Playwright verwendete, schrieb alle zehn Fälle und stabilisierte sie während des Hackathons selbst.

Nur ein anderer Ansatz schloss ebenfalls alle zehn Fälle ab: striktes Record-and-Play. Playwright mit AND-Code-Unterstützung erreichte die gleiche Fertigstellung und blieb dabei codebasiert.

Das Ergebnis birgt einen Vorbehalt, den es zu beachten gilt. Die generierten Tests wurden nicht auf Wartbarkeit hin entwickelt. Wenn sich etwas änderte, musstest du wahrscheinlich den gesamten Test neu aufzeichnen, ähnlich wie bei einem Record-and-Play-Tool. Der Hackathon hat bewiesen, dass die Tests möglich sind, aber nicht, dass sie dauerhaft sind.

Das breitere Team kam bei einer abschließenden Demo, bei der jeder sein Tool und seine Meinung zeigte, zu demselben Schluss. Ein paar Optionen schnitten gut ab. Keine konnte mit Playwright konkurrieren.

Warum kritische Pfade bei einer Migration an erster Stelle stehen

Migriere die kritischsten Tests zuerst, denn sie müssen am schnellsten sein und schneiden eine vertikale Schneise durch das System. Displate gliedert die Ende-zu-Ende-Tests in drei Ebenen, und die Reihenfolge der Migration folgt dieser Struktur.

Die Top 10 sind die kritischen Geldwege, die gegen die Produktion laufen. Es ist nicht einfach, diese Tests zu schreiben, aber wenn du sie zuerst durchführst, hast du ein funktionierendes Sicherheitsnetz für das neue Framework und kannst die schwierigen Fragen der Integration frühzeitig klären.

Von da an ist der Plan schrittweise. Neue Funktionen werden nur in Playwright geschrieben. Bestehende Cypress-Tests werden verschoben, wenn eine wirkliche Logikänderung erforderlich ist; ein trivialer Locator-Fix kann immer noch in Cypress gepatcht werden, bis der Test an der Reihe ist.

Was eine Migration auch nach gründlicher Recherche überrascht

Selbst bei einer sorgfältigen Evaluierung werden Dinge übersehen, weil Frameworks dieselbe Aufgabe unterschiedlich handhaben. Die Sitzungsverwaltung hat das Team überrumpelt.

Displate führt viele A/B-Tests durch und speichert Daten im lokalen Speicher, im Sitzungsspeicher, im Cache und in Cookies. Die Tests laufen sowohl in der Produktions- als auch in der Testumgebung, denn keine Testumgebung ist so nah an der Produktion wie die Produktion selbst. Deshalb müssen die Tests zuerst die analytischen Cookies entfernen, da sie sonst die echten Daten verunreinigen.

Dieses Risiko ist nicht hypothetisch. Eine Posterseite, die im Rahmen der Testautomatisierung stark genutzt wurde, verzeichnete so viele tägliche Besuche, dass ein Mitarbeiter des Unternehmens vorschlug, den Künstler wegen einer Werbeaktion anzusprechen. Er hielt den Testverkehr für echtes Interesse, das aber nicht zu einer Konversion führte.

Das Abfangen von API-Anfragen, von dem man annahm, dass es in allen Frameworks gleich ist, war es nicht. In Cypress dauerte das Abfangen einer Berechtigungsanfrage etwa zwei Zeilen. In Playwright musste das Team in der verstreuten Dokumentation nach der richtigen Einstellung suchen. In Cypress war es einfach, Hosts über eine Konfigurationsoption zu blockieren; in Playwright mussten sie die Logik zum Blockieren von Hosts selbst schreiben. In der Auswertungstabelle tauchte nichts davon auf, weil sie davon ausgingen, dass die Bearbeitung von Anfragen dies impliziert.

Eine subtilere Falle ist das Umschreiben statt Umdenken. Das Team hatte sich darauf geeinigt, den Cypress-Code nicht Zeile für Zeile zu portieren, sondern die Tests anhand der Logik neu zu erstellen. Unter Termindruck und da das neue Tool noch nicht vollständig beherrscht wurde, verfiel man wieder darauf, Cypress-Muster in Playwright zu übersetzen. Das ist eine ganz normale Fehlerauswirkung, an der niemand schuld ist.

Wie man Kapazitäten für die Migration innerhalb der normalen Lieferung findet

Die Kapazität für die Migration ergibt sich aus der Prioritätensetzung und dem Timing, nicht aus zusätzlichen Stunden. Displate hat den größten Teil des Dezembers genutzt, weil in der Weihnachtszeit wenig neue Funktionen entwickelt werden. Die Wochen vor dem Black Friday bis Weihnachten sind die Zeit, in der das Unternehmen das meiste Geld verdient, also bleiben große Funktionen aus und der Kalender öffnet sich für Bereinigung und Migration.

Das Team arbeitet wie ein Plattformteam und nicht wie ein Tester pro Lieferteam. Die meisten Entwicklerinnen und Entwickler testen ihre eigene Arbeit, und die Qualitätsingenieure leisten Unterstützung: Sie recherchieren, wie man Zahlungen in einem neuen Markt testet, oder finden heraus, wie man etwas abdeckt, von dem ein Team keine Ahnung hat, wie man es testet. Durch dieses Modell wird Zeit für die Wartung frei, aber nur, wenn die Roadmap es zulässt.

Die ehrliche Version der Kapazitätsplanung räumt ihre Grenzen ein. Mit Blick auf die Zukunft rechnete das Team in einigen Monaten mit wenig Automatisierungszeit und fror einen Teil der Kapazität im Backlog ein, anstatt so zu tun, als ob die Arbeit einfach passen würde. Im Moment sorgt eine Rotation dafür, dass zwei Leute die Teams unterstützen, während einer die Automatisierung schreibt, so dass jeder eine Hand am neuen Tool hat.

Wo KI in die Migration selbst passt

KI kann den Übergang beschleunigen, wobei die Frage der Wartbarkeit noch offen ist. Ein Entwickler experimentierte mit Cursor, um Tests von Cypress nach Playwright zu übersetzen. Dazu gab er dem KI-Agenten das Cypress-Repository, die Playwright-Dokumentation und den Playwright-Zielcode und bat ihn dann, einen bestimmten Test zu erstellen.

Nach ein paar Versuchen hat er Tests erstellt, die funktionierten. Der Haken an der Sache ist derselbe, der sich durch das ganze Thema zieht: Ob die übersetzten Tests wartbar sind, ist noch nicht bewiesen. Die Demo für das breitere Team misslang an diesem Tag, auch wenn frühere private Versuche erfolgreich waren.

Realistisch ist, dass bessere Prompts und ein besserer Umgang des Teams mit dem Tool die Geschwindigkeit beim Schreiben und Übersetzen von Tests mit der Zeit erhöhen werden. Betrachte die KI-Übersetzung als ein Werkzeug, das gelernt werden muss, und nicht als einen Schalter, der die Migration für dich erledigt.

Die Einbeziehung von Front-End-Entwicklern in die Automatisierung ist der parallele Gewinn. Bei Playwright beteiligen sich die Entwickler an Pull Requests, und der Plan ist, sie ihre eigenen Tests schreiben und pflegen zu lassen, sobald die Top 10 stabil sind. Diese Umstellung, die schon lange gewünscht wurde und mit Playwright einfacher ist als mit Cypress, ist vielleicht wichtiger als die Wahl des Frameworks selbst.