Umstellung von Cypress auf Playwright

Ein Team sah sich mit zunehmenden Reibungsverlusten bei Ende-zu-Ende-Tests konfrontiert und führte einen sauberen Vergleich von Cypress und Playwright durch. Rechthaberische Workflows, Plugins, Iframe-Probleme, fehlerhafte Screenshots und eine Paywall für parallele Läufe hatten die Lieferung verlangsamt. Ein gemeinsamer Hackathon mit Entwicklern und Testern ergab Skripte, Zeitpläne und Fehlerwirkungen. Playwright hatte die Nase vorn, wenn es um Geschwindigkeit, browserübergreifende Unterstützung und Kontrolle über Netzwerk und Kontext ging. Die frühe Migration zielt auf die wichtigsten Benutzerströme und Produktions-Smoke-Checks ab. Cookies, A/B-Flags und das Abfangen von Anfragen haben die Einrichtung und die Ausstattung neu gestaltet. Die Kapazität bleibt knapp, doch die Umstellung macht einen weiteren Punkt deutlich. Die Wahl des Tools ist eine Produktstrategie.

Podcast Episode: Umstellung von Cypress auf Playwright

In dieser Folge spreche ich mit Maciej Wyrodek über den Wechsel von Cypress zu Playwright. Wir sprachen darüber, warum Cypress anfing, gegen das Team zu arbeiten: rechthaberischer Stil, Plugin-Churn, iFrames, unzuverlässige Screenshots und eine Preisschranke für parallele Läufe. Maciejs Antwort war ein praktischer Hackathon mit Entwicklern und Testern. Playwright hat gewonnen. Die Migration begann mit ihren Top-10-Flows und Produktions-Smokechecks.

"There is a lot of our custom admin stuff like managing artworks, managing the copyrights, managing work with the artist. So there is a lot of custom code there. So it's not just simple E-commerce." - Maciej Wyrodek

Maciej Wyrodek ist Wissenssucher, Qualitätsberater, Mentor und Trainer - spezialisiert auf Testautomatisierung und Prozessverbesserung.Maciej ist immer auf der Suche nach neuen Herausforderungen und Möglichkeiten, seine Fähigkeiten zu verbessern. Er hat Erfahrungen in verschiedenen Unternehmen mit unterschiedlichen Arbeitsmodellen gesammelt, von kleinen bis hin zu großen Konzernen, vom Produkt über die interne Entwicklung bis hin zum Softwarehaus. Dank dieser Erfahrung hat er einen umfassenden Einblick in das Testen von Qualität und die Schaffung von Mehrwert.Während seines Aufenthalts in Dublin hat er seine Leidenschaft entdeckt: Die Weitergabe von Wissen.Er ist der festen Überzeugung, dass das, was uns zu Menschen macht, die Fähigkeit ist, zu lernen und Wissen zu teilen.Aus diesem Grund tut er seit fast zehn Jahren sein Bestes, um der IT-Gemeinschaft etwas zurückzugeben, indem er Artikel schreibt, Videos auf seinem Kanal Itea Morning aufnimmt und auf Konferenzen spricht.

Highlights der Episode

• Cypress Plugin Churn, iFrames, fehlerhafte Screenshots und parallele Preisgestaltung schaden der Produktivität
• Ein gemeinsamer Hackathon brachte das Team dazu, sich für Playwright zu entscheiden
• Start der Migration mit Top Business Flows und Smoke-Tests in der Produktion
• Handhabung von Cookies, A/B-Tests und Abfangen von Anfragen im Setup
• Autonome Test-Bots klickten ziellos herum und waren nicht hilfreich

Lektionen zur Auswahl und Umstellung von Testautomatisierungsframeworks

Testautomatisierung neu denken: Wenn das Werkzeug nicht mehr passt

Für viele Entwicklungsteams ist Cypress die Standardlösung für die Testautomatisierung im Web. Es ist beliebt, leicht zu erlernen und das Ökosystem floriert. Aber was passiert, wenn Ihr wachsendes Projekt an die Grenzen des gewählten Test-Frameworks stößt?

Genau das ist Maciej Wyrodek und seinem Team bei Displate passiert. In einer kürzlich erschienenen Folge von Software Testing Unleashed erzählte Maciej, wie - und warum - sie die Entscheidung getroffen haben, eine umfassende Migration von Cypress zu Playwright vorzunehmen, und erläuterte den Prozess mit Einblicken, praktischen Ratschlägen und einigen überraschenden Ergebnissen.

Erkennen, wann es Zeit für eine Veränderung ist

Maciej hat sich die Entscheidung nicht leicht gemacht. Als er zu Displate kam, war Cypress bereits für die Frontend-Automatisierung im Einsatz, und als neuer Leiter der Qualitätssicherung entschied er sich zunächst dafür, die Anwendung auch auf Backend-Geschäftssysteme auszudehnen - vor allem, um keine Unruhe zu stiften. Im Nachhinein stellte er jedoch fest, dass die Design-Entscheidungen von Cypress und die starken Meinungen darüber, wie Tests geschrieben werden sollten, nicht gut mit den Bedürfnissen seines Teams übereinstimmten.

Im Laufe des Projekts traten mehrere Probleme immer deutlicher zutage:

• Die eigenwillige API von Cypress und die Abhängigkeit von einer wachsenden Anzahl von Plugins erschwerten die Anpassung und Wartung von Tests.
• Die Interaktion mit Iframes und bestimmten Integrationspunkten (z. B. Zahlungsanbietern von Drittanbietern) erwies sich als umständlich und erforderte mehrere Umgehungslösungen.
• Probleme mit der visuellen Rückmeldung, wie z. B. unzuverlässige Ganzseiten-Screenshots bei Fehlerwirkungen von Tests, erschwerten das Debugging.

Neben den technischen Hürden spielten auch geschäftliche Erwägungen eine entscheidende Rolle. Der Bedarf des Teams an erschwinglicher Parallelisierung führte es zu einem Drittanbieterdienst, Currents. Als Cypress jedoch Schritte unternahm, die die Unterstützung von Currents in neueren Versionen blockierten, schwand das Vertrauen und Displate sah sich gezwungen, sich anderweitig umzusehen.

Buy-In aufbauen und einen Weg nach vorne aufzeigen

Der Wechsel von Frameworks in einer aktiven, funktionsreichen Umgebung ist keine Kleinigkeit. Das Team stand vor der doppelten Herausforderung, wichtigen Automatisierungscode zu migrieren und gleichzeitig die tägliche Produktentwicklung und Qualitätssicherung aufrechtzuerhalten.

Ihre Strategie begann mit einer klaren Reflexion: Was nutzten sie tatsächlich und was gefiel ihnen an Cypress? Welche Probleme wollten sie unbedingt lösen? Auf dieser Grundlage stellte Maciejs Team eine Matrix mit Anforderungen zusammen, in der "Must-haves", "Nice-to-haves" und "Show-stoppers" für jedes neue Tool aufgeführt waren.

Ein gemeinschaftlicher Hackathon: Testen von Tools, nicht nur von Funktionen

Anstatt sich bei der Entscheidung ausschließlich auf die Dokumentation oder die Angebote der Anbieter zu stützen, organisierte das Team einen praktischen Hackathon. Sieben Tool-Kandidaten traten gegeneinander an und wurden jeweils von kleinen Gruppen (darunter Entwickler und QA-Ingenieure) anhand von zehn realen Testfällen aus dem Displate-Bereich bewertet.

Was stach heraus?

Playwright kristallisierte sich schnell als Spitzenreiter heraus - nicht nur wegen seines Funktionsumfangs, sondern auch wegen seiner praxisnahen Leistung und der Einfachheit, stabile Tests zu starten.

Einige Tools verloren schnell an Boden, entweder aufgrund schlechter Dokumentation, veralteter Anleitungen oder einer Fehlerwirkung, die den praktischen Anforderungen des Arbeitsablaufs des Teams nicht gerecht wurde.

Experimente mit KI-basierten Tools hatten zwar einen gewissen Unterhaltungswert - ein Skript, das minutenlang nach dem Zufallsprinzip über die Website wanderte, bevor es ein Szenario abschloss -, waren aber für die Produktionsmigration noch nicht zuverlässig genug.

Wichtig war, dass das Team die Anpassung durch eine Demo am Ende des Hackathons sicherstellte. Während einige andere Frameworks bewundernswerte Leistungen erbrachten, fand die Kombination aus Flexibilität, Community und praktischen Ergebnissen von Playwright breite Zustimmung.

Verwaltung der Migration: Top-Down, iterativ und realistisch

Nachdem die Entscheidung für Playwright gefallen war, begann die harte Arbeit der Migration. Das Team priorisierte zunächst die kritischsten Tests - die zehn wichtigsten End-to-End-Szenarien, die für den Geschäftswert entscheidend sind - und migrierte sie während der Entwicklungspause für neue Funktionen im Dezember. Von da an war ihr Ansatz pragmatisch:

• Die Tests für neue Funktionen sollten künftig in Playwright geschrieben werden.
• Alte Cypress-Tests wurden opportunistisch migriert - vor allem dann, wenn größere Refactors oder fehlgeschlagene Tests es nahe legten, sie im neuen Framework zu überarbeiten.
• Dabei kam es zu Überraschungen: Bestimmte Cypress-Funktionen, wie das Abfangen von API-Anfragen und die Sitzungsverwaltung, funktionierten in Playwright anders, so dass manchmal benutzerdefinierte Hilfsprogramme oder neu überdachte Ansätze erforderlich waren.

Die Rolle der KI und ein Blick in die Zukunft

Während die manuelle Programmierung weiterhin im Mittelpunkt steht, experimentiert das Team mit KI-Tools wie Cursor, um die Migration zu unterstützen, den Cypress-Code in Playwright zu übersetzen und routinemäßige Neuschreibungen zu beschleunigen. Die ersten Ergebnisse sind vielversprechend, wenn auch gelegentlich unvorhersehbar. Maciej erwartet mit der Reife der Tools eine weitere KI-Integration.

Wird das Team die Migration in diesem Jahr abschließen? Das hängt davon ab - die Ressourcenplanung ist noch nicht abgeschlossen, und die geschäftlichen Anforderungen haben immer Vorrang. Mit der zunehmenden Akzeptanz von Playwright sowohl bei der Qualitätssicherung als auch bei den Entwicklern sieht die Zukunft der Testautomatisierung bei Displate jedoch kollaborativ, wartbar und lernfähig aus.

Abschließende Überlegungen:Maciejs ehrliche Überlegungen bieten praktische Lektionen für jedes Team, das mit Tool-Müdigkeit konfrontiert ist oder die Testautomatisierung skalieren muss. Die wichtigsten Erkenntnisse: Verstehen Sie Ihren Kontext, binden Sie das gesamte Team ein, testen Sie Tools in Ihrer realen Umgebung, erwarten Sie Überraschungen und passen Sie sich kontinuierlich an - sei es durch Prozessoptimierungen oder aufkommende Technologien wie KI.