Revision 537: Was gibt es Neues in Cypress 9 und 10?

Nachdem es vor zwei Revisionen um das Zusammenspiel von Cypress mit Vitest ging, wollen wir diese Revision ganz exklusiv Cypress widmen und über neue Features aus den Major-Releases 9 und 10 sprechen. Das letzte Mal haben wir das nämlich vor anderthalb Jahren gemacht. Dafür haben wir uns und die beiden Deutschen Cypress Ambassadore Ramona Schwering von Shopware und (erneut) Tobias Struckmeier von der Adesso eingeladen.

Schaunotizen

[00:00:58] Neues in Cypress 9 und 10

Das erste neue Feature, das wir beleuchten, ist das „Component Testing„, das derzeit noch in Beta ist. Beta unter anderem auch deswegen, weil es derzeit nur im Zusammenspiel mit React richtig gut läuft, mit Vue nur noch gut und mit Angular noch gar nicht so richtig.

Wie der Name schon andeutet, erlaubt es das Durchtesten isolierter UI-Bausteine, aber in echten Browsern anstatt in einer per JSDom simulierten Browser-Umgebung wie sie oft zum Einsatz kommt. Das ist zwar aufwendiger und langsamer, Fehler können damit aber besser debugged werden, weil die entwickelnde Person bei Auftreten eines solchen einfach den Browser übernehmen, die Devtools öffnen und mit der Fehlersuche beginnen kann. Dieses Feature führt aber leider zu einer neuen Projektstruktur, die zwischen E2-E und Component-Testing aufteilt, und die noch ein paar weitere Änderungen mit sich bringt. Wichtig zu wissen für eine Migration von einer älteren Cypress-Version – die allerdings recht schnell von der Hand geht.

Andere Tools zum Entwickeln von Komponenten wie Storybook ersetzt dieses Feature nicht. Andersherum bietet Storybook aber mittlerweile mit „Storybook Play“ ein eigenes Testing-Feature.

Als nächstes sprechen wir über Cypress Studio, welches man derzeit als experimentell einstufen muss, weil dessen Zukunft in Frage gestellt wird. Cypress Studio ermöglicht es, Cypress-Tests WYSIWYG-artig zu erstellen, was Nicht-Entwickelnden einen Zugang zum Erstellen von Tests öffnet. In Frage gestellt deswegen, weil die Chrome Devtools neuerdings mit dem „Recorder“ daherkommt, der User-Flows aufzeichnet, die man mit Hilfe von Browser-Plugins abgreifen und in eigene Tools und Formate exportieren kann.

Wir widmen uns in dem Zusammenhang der Frage, wie robust und dauerhaft rein visuell anstelle von semantisch zusammengestellte Tests sein können und sind uns darin einig, dass sie deutlich fragiler sind. Allerdings sind sie definitiv ein guter Einstieg in die Welt der Test-Erstellung und mit zunehmender Erfahrung wird es immer mehr möglich, diese als Vorlage zu betrachten, die man Anschluss „robust“ macht. Auch lässt sich Cypress vorab ein Stück weit so einstellen, dass es bestimmte HTML-Strukturen bevorzugt als Orientierungspunkte heranzieht als andere (bestimmte Attribute vs. CSS-Selektorkette).

Das dritte neue Feature, über das wir sprechen, ist ebenfalls noch experimentell: Das Multi-Domain-Testing. Multi-Domain-Testing ist traditionell ein blinder Fleck aller Testing-Tools, und zwar weil es technisch aufwändig oder sogar unmöglich ist. Es geht dabei darum, dass Tests auch möglich sind, wenn der User-Flow die primäre Domain zeitweilig verlässt, wie es zum Beispiel bei einem Login via externer Dienste der Fall ist, oder auch bei einer Zahlung über einen externen Zahlungsdienstleister. In Revision 442 sprachen wir dazu auch mit Marvin Hagemeister, der aus diesem Grund zusammen mit Kollegen sein eigenes Testing-Framework gebaut hat, das das kann. Dass sowas jetzt auch mit Cypress möglich ist, ist u.a. in der ebenfalls experimentellen „Session API“ zu begründen. Diese ermöglicht es, Cookies und LocalStorage-Daten über mehrere Tests hinweg zu persistieren. Das macht es auch möglich, bestimmte Arten von Tests zu beschleunigen, indem man die ganze Setup-Arbeit einmal macht, abspeichert und fortan nur noch lädt.

Das führt uns zu dem letzten diskutierten Themenblock, nämlich die Ausführungsgeschwindigkeit von Cypress-Tests und wie man die schnell hält. Ramonas Strategie ist, ein Basis-Set für die schnellen und wichtigsten Tests zu nutzen, um die Pipeline schnell zu halten, und dazu einen „Nightly Build“-Ansatz zu fahren, bei dem jede Nacht alles aufwendig abgetestet wird. Eine weitere Möglichkeit ist die Parallelisierung per Ordner oder Segmentierung via Tags, und das Ganze auf mehreren Maschinen orchestriert via Cypress Dashboard. Am längsten dauert aus ihrer Sicht aber immer das initiale Setup der Testdaten – und da unterscheidet sich Cypress nicht von anderen Tools. Und schließlich sind wir uns auch einig, dass keine 100% Testabdeckung notwendig ist, weil einfach zu teuer.

[00:00:00] Links

An Update on Cypress Studio

Ein Blogpost vom Cypress-Team mit dessen Überlegungen zu Cypress Studio.

Cypress 10.2.0: Run tests up to 2x faster on Apple silicon (M1)

Seit Version 10.2 läuft Cypress nicht mehr in einer Intel-Emulation, sondern nativ mit dem ARM-Befehlssatz.

Storybook Play

Storybook bietet mit Play nun einen eigenen Test-Workflow.

Vitest

Ein auf Vue maßgeschneidertes Testing-Framework. Mehr dazu in Revision 535.