BROADCASTS.com

Nachdem es vor zwei Revisionen um das Zusammenspiel von Cypress mit Vitest ging,\nwollen wir diese Revision ganz exklusiv Cypress widmen und \xfcber neue Features\naus den Major-Releases 9 und 10 sprechen. Das letzte Mal haben wir das n\xe4mlich\nvor anderthalb Jahren gemacht. Daf\xfcr haben wir uns und die beiden Deutschen\nCypress Ambassadore Ramona Schwering von Shopware und (erneut) Tobias\nStruckmeier von der Adesso eingeladen.\n\n\nSCHAUNOTIZEN\n\n[00:00:58] NEUES IN CYPRESS 9 UND 10\n\nDas erste neue Feature, das wir beleuchten, ist das \u201eComponent Testing\u201e, das\nderzeit noch in Beta ist. Beta unter anderem auch deswegen, weil es derzeit nur\nim Zusammenspiel mit React richtig gut l\xe4uft, mit Vue nur noch gut und mit\nAngular noch gar nicht so richtig.\n\n\n\nWie der Name schon andeutet, erlaubt es das Durchtesten isolierter UI-Bausteine,\naber in echten Browsern anstatt in einer per JSDom simulierten Browser-Umgebung\nwie sie oft zum Einsatz kommt. Das ist zwar aufwendiger und langsamer, Fehler\nk\xf6nnen damit aber besser debugged werden, weil die entwickelnde Person bei\nAuftreten eines solchen einfach den Browser \xfcbernehmen, die Devtools \xf6ffnen und\nmit der Fehlersuche beginnen kann. Dieses Feature f\xfchrt aber leider zu einer\nneuen Projektstruktur, die zwischen E2-E und Component-Testing aufteilt, und die\nnoch ein paar weitere \xc4nderungen mit sich bringt. Wichtig zu wissen f\xfcr eine\nMigration von einer \xe4lteren Cypress-Version \u2013 die allerdings recht schnell von\nder Hand geht.\n\nAndere Tools zum Entwickeln von Komponenten wie Storybook ersetzt dieses Feature\nnicht. Andersherum bietet Storybook aber mittlerweile mit \u201eStorybook Play\u201c ein\neigenes Testing-Feature.\n\nAls n\xe4chstes sprechen wir \xfcber Cypress Studio, welches man derzeit als\nexperimentell einstufen muss, weil dessen Zukunft in Frage gestellt wird.\nCypress Studio erm\xf6glicht es, Cypress-Tests WYSIWYG-artig zu erstellen, was\nNicht-Entwickelnden einen Zugang zum Erstellen von Tests \xf6ffnet. In Frage\ngestellt deswegen, weil die Chrome Devtools neuerdings mit dem \u201eRecorder\u201c\ndaherkommt, der User-Flows aufzeichnet, die man mit Hilfe von Browser-Plugins\nabgreifen und in eigene Tools und Formate exportieren kann.\n\nWir widmen uns in dem Zusammenhang der Frage, wie robust und dauerhaft rein\nvisuell anstelle von semantisch zusammengestellte Tests sein k\xf6nnen und sind uns\ndarin einig, dass sie deutlich fragiler sind. Allerdings sind sie definitiv ein\nguter Einstieg in die Welt der Test-Erstellung und mit zunehmender Erfahrung\nwird es immer mehr m\xf6glich, diese als Vorlage zu betrachten, die man Anschluss\n\u201erobust\u201c macht. Auch l\xe4sst sich Cypress vorab ein St\xfcck weit so einstellen, dass\nes bestimmte HTML-Strukturen bevorzugt als Orientierungspunkte heranzieht als\nandere (bestimmte Attribute vs. CSS-Selektorkette).\n\nDas dritte neue Feature, \xfcber das wir sprechen, ist ebenfalls noch\nexperimentell: Das Multi-Domain-Testing. Multi-Domain-Testing ist traditionell\nein blinder Fleck aller Testing-Tools, und zwar weil es technisch aufw\xe4ndig oder\nsogar unm\xf6glich ist. Es geht dabei darum, dass Tests auch m\xf6glich sind, wenn der\nUser-Flow die prim\xe4re Domain zeitweilig verl\xe4sst, wie es zum Beispiel bei einem\nLogin via externer Dienste der Fall ist, oder auch bei einer Zahlung \xfcber einen\nexternen Zahlungsdienstleister. In Revision 442 sprachen wir dazu auch mit\nMarvin Hagemeister, der aus diesem Grund zusammen mit Kollegen sein eigenes\nTesting-Framework gebaut hat, das das kann. Dass sowas jetzt auch mit Cypress\nm\xf6glich ist, ist u.a. in der ebenfalls experimentellen \u201eSession API\u201c zu\nbegr\xfcnden. Diese erm\xf6glicht es, Cookies und LocalStorage-Daten \xfcber mehrere\nTests hinweg zu persistieren. Das macht es auch m\xf6glich, bestimmte Arten von\nTests zu beschleunigen, indem man die ganze Setup-Arbeit einmal macht,\nabspeichert und fortan nur noch l\xe4dt.\n\nDas f\xfchrt uns zu dem letzten diskutierten Themenblock, n\xe4mlich die\nAusf\xfchrungsgeschwindigkeit von Cypress-Tests und wie man die schnell h\xe4lt.\nRamonas Strategie ist, ein Basis-Set f\xfcr die schnellen und wichtigsten Tests zu\nnutzen, um die Pipeline schnell zu halten, und dazu einen \u201eNightly Build\u201c-Ansatz\nzu fahren, bei dem jede Nacht alles aufwendig abgetestet wird. Eine weitere\nM\xf6glichkeit ist die Parallelisierung per Ordner oder Segmentierung via Tags, und\ndas Ganze auf mehreren Maschinen orchestriert via Cypress Dashboard. Am l\xe4ngsten\ndauert aus ihrer Sicht aber immer das initiale Setup der Testdaten \u2013 und da\nunterscheidet sich Cypress nicht von anderen Tools. Und schlie\xdflich sind wir uns\nauch einig, dass keine 100% Testabdeckung notwendig ist, weil einfach zu teuer.\n\n\n[00:00:00] LINKS\n\nAN UPDATE ON CYPRESS STUDIO\n\nEin Blogpost vom Cypress-Team mit dessen \xdcberlegungen zu Cypress Studio.\n\nCYPRESS 10.2.0: RUN TESTS UP TO 2X FASTER ON APPLE SILICON (M1)\n\nSeit Version 10.2 l\xe4uft Cypress nicht mehr in einer Intel-Emulation, sondern\nnativ mit dem ARM-Befehlssatz.\n\nSTORYBOOK PLAY\n\nStorybook bietet mit Play nun einen eigenen Test-Workflow.\n\nVITEST\n\nEin auf Vue ma\xdfgeschneidertes Testing-Framework. Mehr dazu in Revision 535.