Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und habe wieder eine Folge vom German Testing Day 2024 mit im Gepäck. Bei mir zu Gast heute Felix Wunderlich von Volkswagen, der mit einer steilen These aufwartet, denn warum sollte man eigentlich Webkomponenten testen, wenn man eigentlich auch die UI testen kann. Als ich das gelesen habe, habe ich mir gedacht, das ist eigentlich genau umgekehrt, oder? Naja,
dieser Frage gehen wir nach. Viel Spaß bei der Folge. Hallo Felix, schön, dass du da bist. Ja, hallo Ritschi, schön, dass ich da sein kann. Ja, sehr schön. Wir haben uns ja schon drinnen bei der Eröffnung kurz gesehen, ich musste dann weiterziehen, aber wir haben ja auch kurz schon gesehen. Tolle Veranstaltung hier, German Testing Day 2024, 400 Leute oder was? Wahnsinn, richtig was los. Da gibt es was, ja. Dein Vortrag kommt erst, oder? Richtig, genau.
Ja, also da werden dann wahrscheinlich auch 399 sein. Hoffentlich. Mal sehen. Du hast ja in deinem Abstract, habe ich gelesen, habe ich schon gedacht, oh, der ist ja mutig. Da steht so etwas drinnen, ja, warum eigentlich Komponenten testen, wenn wir auch gleich die UI testen können? Und oft hört man es ja eigentlich genau umgekehrt. Und dann habe ich gedacht, da müssen wir uns jetzt mal unterhalten drüber. Darum bist du jetzt hier.
Ja, das ist doch prima. Genau, also ich habe vor fünf Jahren bei VW angefangen und dort gab es eigentlich nur zwei Tests, was das Frontend angegangen ist. Nämlich auf der einen Seite die End-to-End-Tests, bei denen man sehr viel Aufwand betreiben muss und die liefen dann im Browser. So Standard mit damals noch Selenium und Protractor. Heutzutage gibt es ja Playwright
oder Cypress. Und auf der anderen Seite gab es immer diese Komponententests. Und irgendwie, ja, war das so unbefriedigend, weil so ein Komponententest, der ist ja sehr isoliert und sehr klein und dieser End-to-End-Test, der hat eigentlich ganz viele Komponenten, die überhaupt nichts mit meinem schönen Frontend zu tun haben, was ich ja gerade testen möchte.
Und wir haben uns einfach sehr lange geärgert und dann haben wir irgendwann gesagt, also es muss besser gehen und haben eine Möglichkeit gefunden, um das Frontend isoliert zu testen als ganze Anwendung und nicht einfach nur als Teile sozusagen davon. Und das macht uns sehr viel Freude. Ja, das sieht man, du strahlst hier auch. Absolut. Genau, weil man halt die Nutzerperspektive abbildet. Das ist das,
was bei den anderen immer irgendwie gefehlt hat. Und ja, das macht sehr viel Spaß und deswegen bin ich auch hier jetzt heute und werde das hoffentlich weiter verbreiten können. Ja, bevor wir da nochmal, jetzt muss man da ein paar Sachen klarstellen. Jetzt hast du gesagt VW, da denkt man ja zuerst jetzt nicht an eine Website. Ne, das stimmt, ja. Zu einem alten Auto.
Ja, genau. Aber jetzt geht es bei euch schon darum, Webseiten von, weiß ich nicht, wo man sich das Auto dann zusammen klickert oder von, weiß ich nicht, oder was? Ja, also ich konkret bin in einem Team, wir schreiben Software für die Werkstätten. Das heißt also wir schreiben wirklich Anwendersoftware entweder konzernintern oder sozusagen für unsere
Kunden da draußen. Okay, gut. Das ist wichtig. Und dann hast du gesagt, also End-to-End-Tests, da kann ich mir jetzt was darunter vorstellen, Komponententests, also wie klein sind denn die Komponententests gewesen? Waren das so wie Unit-Tests gedacht oder schon so ein bisschen mehr? Meistens waren es eher Unit-Tests. Also entweder, dass man so eine Einzelkomponente per Jest oder Mocker oder was auch immer in so einen kleinen DOM reinhängt und die dann irgendwie einzeln
durchtestet. Und manchmal gibt es dann dann noch so Verbundtests, wo die dann irgendwie, ja, so eine ganze Form oder so da testen. Aber so richtig befriedigend war das alles nicht, weil jedes Mal, wenn man die UI umgebaut hat oder dann eine Komponente dazu stecken muss, sind ganz viele Tests kaputt gegangen, die ich gar nicht anfassen wollte. Okay, und dann gab es die End-to-End-Tests, die wirklich dann so alles miteinander dann auch miteinander getestet haben und dazwischen irgendwie nichts.
Ja, genau. Mehr oder minder. Also bei den End-to-End-Tests haben wir meistens so eine dockerisierte Umgebung mit eigener Datenbank, eigenem Testdatenmanagement. Das ist ja dann eine riesen Angelegenheit. Das ist einfach aufwendig und da so einzelne Teile der UI oder Fehlerfälle abzutesten, ist einfach nicht wirtschaftlich, sagen wir es ganz ehrlich. Ja, gut. Und dann habt ihr gesagt, das geht jetzt auch anders. Wir wollen das aus der
Nutzersicht machen. Wir wollen schön die UI testen. Wie habt ihr euch denn dem genähert? Ja, wir haben dann irgendwann entdeckt, dass sowohl Cypress als auch TestCafe als auch Playwright, quasi da läuft die Anwendung ja in so einem Browser-Kontext irgendwie und in diesem Kontext kann man also die Requests abfangen, die an die Backends oder APIs oder Datenbanken oder
wo auch immer hingeschickt werden. Und wenn man sich das zum Nutzen macht und sagt, okay, ich tue jetzt mal so, als wäre da hinten tatsächlich mein echtes System, aber eigentlich fahre ich das gar nicht richtig hoch, sondern ersetze das durch sofort definierte Antworten, dann kann ich mein Frontend als echte Applikation aus Nutzerperspektive quasi isoliert testen, das Ganze auch noch parallel und schnell machen und habe im Prinzip alle Gewinne, die ich
mir so vorstellen kann. Und da haben wir dann ein bisschen rumexperimentiert, haben uns dann auf Playwright geeinigt. Da geht es einfach von den ganzen Aufsätzen, sehr, sehr einfach. Alles, was man machen muss, ist im Test einmal definieren auf der Route, die den Request so und so abfeuert, schickt mal bitte so eine Mock-Response zurück und zack, schon hat man ein funktionierendes Frontend. Okay, das heißt, ihr kapselt quasi das unten alles weg und kümmert euch quasi nur um den UI-Part.
Richtig, genau. Und testet ihr dann dort auch eher so Abläufe oder wie granular ist denn das, was die Testfälle, die ihr dann da durchführt? Wie granular das Ergebnis ist oder wie granular sozusagen der Test an sich ist? Wie ist die Testdurchläufe, also der Ablauf quasi? Ja, das ist so der Part, wo es ein bisschen interessant wird. Also wir verwenden tatsächlich
die ganze Anwendung so, wie es der Nutzer machen würde. Das heißt, sagen wir mal, wir haben ein Widget mit fünf Steps, dann würden wir tatsächlich diese fünf Steps vom Nutzer ausfüllen lassen und dann, wenn wir quasi die Form im letzten Step testen wollen, dann können wir dort einzelne Tests zum Beispiel für Validierung, für unterschiedliche Ergebnisse und so weiter, unterschiedliche Requests, die vielleicht auch ausgehen, durchtesten.
Das kann man alles sehr gut verskripten und ich muss ehrlich sagen, das ist überraschend schnell. Also man stellt sich das so, das ist eigentlich unintuitiv, man stellt sich das so vor, man hat da diesen fünfschrittigen Wizard irgendwie und dann jeder Test, der auf dem letzten Schritt ist, muss erstmal alle davor bedienen. Das ist eigentlich komisch.
Aber das Coole ist, wenn ich das so aufbaue und ich quasi in dem Wizard den Zustand irgendwie ändern muss und das betrifft nur den fünften Zustand, dann stelle ich durch dieses Vorgehen sicher, dass der interne Applikationszustand in meinem Frontend immer noch valide ist. Und das ist cool, weil damit erspare ich mir diese ganzen Anpassungen, die da irgendwie außen rum kommen mit den ganzen Mocks und so, das ist mir dann eigentlich alles egal.
Das ist jetzt schon Geschwindigkeit und auch so ein bisschen Stabilität, weil das wäre auch meine zweite Frage, wenn ich an UI-Tests denke, da fallen mir relativ schnell Sachen ein, wie es ist langsam und es ist instabil. Was machen wir jetzt damit? Ist das alles weg? Ja, sagen wir mal so, es ist schon bedeutend schneller. Dadurch, dass wir halt diese Mock-Responses einsetzen, kann ich ganz viele Tests parallel laufen lassen. Das geht tatsächlich in allen
Frameworks. Ich rede hier immer von Playwright, weil das ist das, was ich jeden Tag verwende. Da kann ich es jetzt machen. Wir haben jetzt aktuell im Team 280 Tests mit UI laufen und ja, ich glaube, das Ganze läuft in unter drei Minuten auf so einer 16 Gigabyte virtuellen Maschine in der Pipeline. Also das ist schon verdammt schnell für 280 Tests, muss man ehrlich sagen. Und von der Stabilität muss ich ehrlich sagen, da gewinne ich ja eigentlich
eher noch, weil ich kann es auf unterschiedlichen Browsern testen tatsächlich. Ich kann es in unterschiedlichen Größen testen. Das heißt, Dinge, die mir manchmal vielleicht erst in der Realität aufgefallen werden, dass da was instabil im Firefox in der Version so und so ist, das sehe ich da plötzlich. Das wird da explizit. Damit gewinne ich eigentlich fast noch nie. Wie viele Tests habt ihr da jetzt umgesetzt? 280, das ist gerade so das Package, das ihr da nutzt. Ja, genau.
Wenn du jetzt so drauf schaust, was ihr da gewonnen habt an diese Kapselung der UI und die Performance und die Stabilität, jetzt so rein aus qualitativer Sicht, hat es was gebracht von der Qualität? Definitiv. Glück gehabt. Ja, was denn? Der Hauptpunkt ist tatsächlich, dass wir bei jedem noch so kleinen Change sicher sein können, dass unsere UI als Gesamtes immer noch so funktioniert, wie sie aus Nutzerperspektive
funktionieren muss. Das heißt, ich kann ganz viel die Code-Qualität meines Frontends besser machen und zum Schluss lasse ich einfach alle Tests laufen und ich weiß genau, solange die noch laufen und das alles funktioniert, ist alles wunderbar. Ich brauche mir keine Sorgen mehr machen. Das war früher mit den Einzelkomponententests nicht so und dann lief irgendwie zehn Minuten lang der E2E-Test und dann ist der letzte schiefgegangen und dann
ging das Ganze von vorne los. Das ist jetzt einfach ein unglaublicher Gewinn für uns, muss man ehrlich sagen. Nutzt ihr das jetzt als Add-on dazu oder habt ihr von den alten Tests, Komponente oder End-to-End auch Dinge jetzt einfach entsorgt, weil ihr sagt, okay, das ist jetzt damit eigentlich auch gut abgedeckt oder ausreichend abgedeckt? Wir haben tatsächlich keine Komponententests mehr. Unser System, das wir entwickelt haben,
das sah am Anfang so einfach aus, dass wir gesagt haben, wir machen nur E2E-Tests. Wir tun uns das gar nicht mehr an. Und daraufhin haben wir gesagt, okay, irgendwann wurden dann aus den End-to-End-Tests irgendwie immer mehr, immer mehr und dann lief das Ding plötzlich auch ewig. Das kennt, glaube ich, fast jeder. Genau. Ja, das ist immer der Fall. Dann häuft sich das und häuft sich das. Und dann haben
wir angefangen durchzugucken und zu sagen, okay, wir sortieren das aus. Wir machen das mit den UI-Tests und haben erst mal alle End-to-End-Tests, die sozusagen nicht, wie sagt man es denn, Userflow relevant waren oder Gesamtsystem relevant waren, erst mal rausgezogen und alle einfach mal in so einen UI-Test gepackt. Da war natürlich jetzt die Migration auch relativ
einfach. Wenn ich jetzt sage, nehmen wir mal an, wir haben ein bestehendes Produkt und da sind schon Komponententests und da sind schon End-to-End-Tests, ist natürlich das Setup-Aufwand am Anfang ganz schön hart, auf diese UI-Tests zu wechseln. Ich möchte immer noch sagen, es lohnt sich deutlich.
Ja, okay, ich merke schon. Ja, sehr gut. Gab es denn irgendwann einmal einen Moment, wo ihr euch nicht sicher wart oder wo es dann schon echt Herausforderungen auch gab bei der Umsetzung, wo ihr gemerkt habt, das läuft jetzt nicht so, wie wir uns das vorgestellt haben? Ja, zwei tatsächlich. Das erste war, wenn man angefangen hat, geteilte Komponenten zu verwenden in unterschiedlichen User-Flows und sie verständlicherweise da quasi doppelt
testen muss. Also bei uns ist es zum Beispiel so, es gibt so einen Button, da klickt man drauf und es ist dann so eine asynchrone Operation und dann läuft da so ein Loading-Spinner und irgendwann, wenn der fertig ist, setzt er so einen grünen Haken. Den haben wir an drei Stellen eingesetzt. Das heißt, es gibt an diesen drei Stellen quasi User-Flow-Tests,
die das machen. Das ist erst mal Duplizierung. Sowas wollen wir eigentlich nicht. Der Vorteil ist, wir hatten das an anderer Stelle in einem komplizierteren Fall auch schon mal, mussten dort irgendwann die Komponenten auseinanderziehen und dann haben wir wieder gewonnen. Aber da waren meine Kollegen schon auch so, also ist es jetzt wirklich notwendig, dass ich den gleichen Test hier an drei Stellen hinschreibe? Das ist eigentlich irgendwie nicht das, was
wir hier wollen. Der zweite Fall ist tatsächlich gewesen, wenn es so um diesen ganzen Setup-Kram geht, also diese ganze Pflege von dem Ganzen. Da waren wir inzwischen schon auch mal an so einem Part, wo sich irgendwie ein CSS-Selector in diesem Playwright-Kram geändert hat und plötzlich mussten wir Dutzende von Tests anpassen. Da haben wir daraus gelernt und dann halt auch Maßnahmen abgeleitet.
Ja gut, das ist ja auch wichtig. Ich finde ja, was ich so raushöre, auch mit der Freude, mit der du das erzählst, ihr habt euch ja echt Gedanken gemacht, wie kann man es besser machen. Viele haben ja solche Ideen, denke ich. In ihrem Team denken sie sich, ach cool, jetzt könnte man mal etwas anders machen. Wie habt ihr diese Idee auch ins Leben gebracht, quasi auch die kritische Masse zu kriegen, sowas umzusetzen? Oder gab es gar keinen Gegenwind?
Also das ist so die zweite Frage dazu. Gab es jemanden, der gesagt hat, Quatsch, dann machen wir nicht. Ja, ich muss ganz ehrlich sagen, im Software Development Center in Wolfsburg haben wir ein sehr, sehr offenes Publikum tatsächlich. Also die Development Teams, die ownen ihre Produkte tatsächlich selber und dadurch ist da schon auch so ein Mindset da, wo man wirklich einfach das Beste auch schaffen will.
Das finde ich jetzt super, dass du das sagst, weil das ist jetzt, wenn man mit dem ICE in Wolfsburg vorbeifährt und diese alten Showanstalten sieht, das ist nicht das, was man unbedingt erwarten würde. Ja, das Software Development Center ist da natürlich ein bisschen Spezialfall. Das ist auf sehr agilen Werten aufgebaut, versteht sich auch quasi als Owner oder als Enabler, um sozusagen die Softwarequalität und die Softwareentwicklung bei Volkswagen voranzutreiben.
Dementsprechend sind dort auch einfach Leute, die gerne mal was Neues ausprobieren und nach dem wir ja den Schmerz hatten, jeder von uns hat den jeden Tag gespürt, das hat wehgetan und auf der anderen Seite war es sozusagen die Migration von diesen End-to-End-Tests, die eh schon zu viele waren, runter auf die UI-Tests, eigentlich vom Aufwand nicht so groß und daraufhin haben wir gesagt, wir machen einfach mal ein Experiment, wir probieren es jetzt einfach mal aus.
Und ja, das hat super geklappt und dieses Experiment hat uns einfach dahin gebracht, dass die Akzeptanz im Team komplett auch da ist. Ja, das ist ja auch immer wichtig, dass das auch einfach im Team auch gut ankommt, dass das quasi auch jeder mitträgt und ich finde das Herangehen über ein Experiment, das mal auszuprobieren, Experiment kann ja auch scheitern und dann sagen, okay, dann war es das nicht, dann machen wir halt weiter mit dem Schmerz, den wir bisher hatten oder suchen wir andere.
Aber das ist auch immer eine schöne Art, um einfach mal was auszuprobieren und zu sehen, ob es funktioniert, was ja in dem Fall auch passiert ist. Jetzt habt ihr diesen Meilenstein geschafft, alle happy, was kommt denn jetzt? Gibt doch sicher den nächsten Schmerzpunkt, der aber noch korrigiert werden muss, oder?
Ja, wir haben uns schon gefragt, wenn jetzt das Produkt so ein paar Jahre lang in Entwicklung ist und wir da erstmal 500 UI-Tests angesammelt haben, dann werden auch die irgendwann langsam. Was machen wir denn dann? Natürlich kann man jetzt immer sagen, ja, dann kriegt die Pipeline eine größere Maschine. Ich werfe Geld auf mein Problem. Das ist halt irgendwie für einen Ingenieur unzufriedenstellend, möchte ich mal behaupten.
Ja, wir haben uns noch überlegt, mit Sharding tatsächlich zu arbeiten, dass man die Tests shardet, dass man die Parallelisierung noch größer hochtreibt. Da haben wir jetzt noch nicht ausprobiert, wie weit man das ausreizen kann, aber ich denke, da geht schon noch einiges. Und sonst an anderer Stelle, gibt es bei euren Tests, die ihr da so macht, noch Schmerzen, wo ihr sagt, okay, da gehen wir jetzt auch ran, auch mit vielleicht einer neuen Idee? Sagen wir mal so, bei den UI-Tests jetzt weniger.
Wir sind eher am Überlegen, das auch tatsächlich in den anderen Produkten, die noch so unter unserer Verantwortung sind, auch mit einzusetzen. Da ist halt, wie gesagt, dieser Migrationsaufwand. Also ich kann jedem, der das probieren möchte, nur einfach raten, sich als allererstes mal seine UI anzuschauen und sich genau aufzuschreiben, mit was die im Hintergrund kommuniziert.
Und dann am besten sowohl die UI-Elemente, also die CSS-Selektoren irgendwo zentral zu sammeln, die Requests zentral zu sammeln, Response-Bilder und Test-Datenbilder zu bauen. Einfach dieses ganze Setup, das da aus nun gehört. Das bereitet halt am Anfang einmal richtig ordentlich Arbeit, muss man ehrlich sagen. Vielleicht auch nicht die schönste Arbeit, gebe ich jetzt zu. Wenn man das mal hat, ist es extrem einfach, weil gerade so Response-Bilder.
Nehmen wir mal an, die Backend-API ändert sich und die schickt plötzlich eine andere Response zurück. Und ich passe meine Response-Bilder an, solange das die UI nicht betrifft, muss alles funktionieren wie vorhin. Ja, genau. Ja, sehr cool. Also ich finde es echt toll, dass ihr da auch diesen Weg setzt und diesen offenen Gedanken auch pflegt, Experimente zu machen, sowas auszuprobieren und hier mal auch einen anderen Weg zu gehen.
Auch mal der vielleicht beim ersten Hören denkt man sich, wieso UI, warum jetzt noch mehr UI, was soll das. Aber es macht ja total Sinn, so wie du es auch erzählst, dass ihr das so umsetzt. In fünf Jahren, German Testing Day 2029, wir stehen hier. Ach Felix, kannst du dich erinnern, wir haben damals vor fünf Jahren ja hier eine Folge aufgenommen. Was ist denn seitdem passiert? Und dann sagst du mir, ja, das willst du jetzt wissen.
Was glaubst du denn in fünf Jahren, was ist das große Highlight, was ihr bei euch noch umgesetzt habt? So als quasi Volkswagen oder jetzt? Also Volkswagen, das will ich gar nicht gegenwärtig sagen. Und bei euch in der Software-Development im Testing-QA-Umfeld? Ich hoffe, dass ich dann sagen kann, dass mehr Teams den Ansatz adaptiert haben. Ich hoffe, dass wir noch mehr miteinander über Best Practices reden.
Ich habe ganz oft festgestellt, dass viele Kollegen grundsätzlich mit der Idee erst mal mitgehen, aber dann halt sehr stark an den Werkzeugen hängen, die sie einfach gerne mögen. Und das ist ja auch vollkommen in Ordnung. Ich bevorzuge auch bestimmte Werkzeuge. Wenn man das jetzt ermöglichen kann, dass sozusagen dieses Konzept UI-Testing für mehrere Werkzeuge akzeptiert ist und damit auch größere Akzeptanz bei allen Entwicklern finden würde, das wäre cool.
Dann könnten wir das quasi breiter ausrollen und dann wäre das vielleicht der neue Standardweg, um seine UI zu testen. Das wäre cool. Ja, sehr cool. Wird dann vielleicht Konzernstandard und irgendwann die Felix-Wunderlich-Methode. Genau, da kann man dann Bücher drüber schreiben. Da lässt sich viel draus machen. Da bleibt man dran in fünf Jahren, wenn mal was passiert. Super, Felix, vielen lieben Dank hier für Rede und Antwort. Ich wünsche dir noch ganz viel Spaß auf der Konferenz hier.
Ja, vielen Dank. Und viel Spaß heute beim Abend-Event und dann morgen auch den Tag dementsprechend dann zu gestalten. Und ja, alles Gute und bis bald. Bis bald. Ja, vielen Dank dir. Ciao. Ciao. Ciao. Ciao. Ciao. [MUSIK] [Ende]