Deep Dive 202 –

Playwright mit Garrelt Mock

03.03.2026

// Podcast
// Deep Dive 202

Shownotes

In dieser Folge werfen Jan und Garrelt gemeinsam mit euch einen Blick auf Playwright, das End-to-End-Testing-Framework von Microsoft. Ihr erfahrt, wie Playwright das Testen von Webanwendungen vereinfacht, indem es Browser automatisiert steuert, Aktionen wie Klicks oder Texteingaben ausführt und gleichzeitig die Ergebnisse validiert. Wir klären, wie sich Playwright von Tools wie Cypress oder Puppeteer unterscheidet und welche Features wie Locators, Assertions oder das Recording von Testaktionen im Alltag wirklich helfen.

Der Fokus liegt klar auf der Praxis: Wir besprechen, wie ihr End-to-End-Tests, Visual Regression Tests und Testdaten sinnvoll aufsetzt, wie parallele Testausführung funktioniert und wie ihr mit flaky Tests umgeht. Jan verarbeitet dabei ganz nebenbei seine Selenium-Traumata aus früheren Projekten – vielleicht kommt euch das bekannt vor.

Gemeinsam diskutieren wir, wann End-to-End-Tests sinnvoll sind und welche Abwägungen zwischen Aufwand und Nutzen Entwickler:innen treffen sollten. Garrelt teilt Einblicke aus der Praxis bei Lotum, etwa wie Tests in CI/CD-Pipelines landen und wie man sie langfristig wartbar hält. Auch das Zusammenspiel von End-to-End- und Unit-Tests spielt dabei eine wichtige Rolle.

Abschließend geben Jan und Garrelt praktische Tipps für den Einstieg in Playwright. von Installation und Setup bis zur Integration in bestehende Projekte. Die Folge schließt mit Empfehlungen für Visual Regression Tests und Überlegungen, wie Teams ihre Testinfrastruktur effizient gestalten, ohne bei der Qualitätssicherung Abstriche zu machen.

Download

/transkript/programmierbar/deep-dive-202-playwright-mit-garrelt-mock

Jan: Herzlich willkommen zu einem neuen Deep Dive hier in der programmier.bar. Heute in 1 kleinen intimen Runde im Podcaststudio hier auf der programmier.bar Couch sitzt neben dem Jan Gregor Inkbetriebe noch der.
Garrelt: Garald Murg. Moin, Garald. Hi, und ich freu mich, ist das das erste Mal in soner Konstellation, wo wir 'n DeepDive machen, ohne, also nur in unserem Core Setup, also in unserem Host Setup so, wie wir's jetzt machen. Sonst hatten wir mal andere Leute aus Loton dabei. Aber haben wir mal nur Hosts gehabt sozusagen, außer?
Jan: Ich glaube nicht. Also die ganz alten Programmierer Schrägstrich Mobil von Folgen, ja, die waren ja auch so, nur wir reden über unsere eigene Arbeit und so, ähnliches Setting.
Garrelt: Stimmt.
Jan: Aber ich glaube, in den letzten 3 Jahren oder so Cool. Gab's das nicht. Find
Garrelt: ich gut. Ja, für mich ist das alles son Experiment heute, weil Jan gesagt hat so, hey, Du kennst doch mit dem Thema aus? Und ich so, geht so. Und dann hat er die Challenge aufgestellt, dass er's schafft, so coole Fragen zu stellen, dass wir eine Stunde darüber reden können. Jetzt bin ich sehr gespannt auf die Fragen.
Jan: Das ist das ist natürlich 'n super krasser Schachzug, Albert, ne, sozusagen, als ob, das das ist so die krasse Lastumkehr gerade so jetzt. Einmal ist es nicht mehr so, man muss das wissen hier so, sondern der Jahrestag sagt, ja, kann die gute Fragen stellen, dass das alles funktioniert, wenn die Folge nix wird. Das ist eindeutig die Schuld vom Jan und nicht die von Augenkanne.
Garrelt: Na, wenn die Folge nix wird, dann wird dir niemand was darüber erfahren. Ja.
Jan: Oder so. Aber jetzt hast Du schon halb gespoilert, das, wie wir dazu bekommen sind. Aber was ist denn das Thema heute?
Garrelt: Es geht Playrite. Ich mein, das sieht man ja auch im Titel, aber was ist Playright, ist wahrscheinlich deine nächste Frage. Playright ist Ich muss
Jan: gar nix machen, das macht
???: Ja, ja.
Jan: Das war alleine. Na, ich
Garrelt: bin ja auch bisschen geübt. Playright ist 'n Testing Framework von Microsoft. Das kam so, ich erinner mich das, ich glaub, vor 3 Jahren auf der NTJS waren da so Talks drüber, wo sie dann das präsentiert haben und meinten so, hey, das ist jetzt irgendwie die neue, neue große Sache. Ich bin mir gar nicht so sicher, wie alt das da war. Das meistens reift das ja schon 'n bisschen. Also ich würde mal schätzen, 4, 5 Jahre ist das alt? Weißt Du?
Jan: Stimmt ja nicht, aber aber das natürlich nicht.
Garrelt: Und Ich spiel
Jan: ja nur zur Frage gestellt, wie er, die man sagen muss.
Garrelt: Und es war son bisschen, also es, genau, es war das neue Testing Framework auf Markt, was irgendwie alles abdecken sollte. Es ist ein end to end Testing Framework. Der Konkurrent dazu ist Zypress, würd ich sagen. Also sie haben, glaub ich, 'n bisschen versucht, das abzulösen und haben's meiner Meinung nach auch geschafft. Playwatch ist sehr verbreitet, sehr featururecomplete. Sie haben vor allen Dingen es halt geschafft, dieses Setup, überhaupt End to End im Web laufen zu lassen, Was
Jan: heißt denn End to End Test für alle, die es vielleicht noch nicht gemacht haben?
???: End
Garrelt: to End Test heißt eben, dass man im Prinzip die Software so laufen lässt, wie sie auf dem Endgerät des User laufen lassen würde. Und dann es schafft, das automatisiert irgendwie zu testen, als würde ein User da rangehen. Also man simuliert einen Buttonklick, guckt, ob die das Ergebnis, also die Seite, wie sie am Ende aussieht, das ist, was man erwartet irgendwie. Also man macht Inputs, man navigiert und guckt, ob das Ergebnis stimmt.
Jan: Ich ich würde das sogar noch krasser formulieren, so, man man simuliert keinen Buttonklick, sondern man macht halt einfach den Buttonklick.
Garrelt: Ja, okay. Deshalb brauchst
Jan: Du ja irgendwie son Browser dazu, Ja. Weil Du halt wirklich sagst, so, in dem Browser wird jetzt dahin geklickt und dann schauen wir mal, was passiert.
Garrelt: Okay, das stimmt. Es ist halt nur kein echter Mensch, der da drauf tippt oder kein Roboter, sondern irgendwie, es ist eine Software, die den Button findet und dann mit Code sagt, ausführt, okay, klickt da mal drauf. Ja. Und ich glaub, da hatte, also ich glaube, dieses Setup war historisch relativ kompliziert. Cypress hatte da, glaub ich, verschieden, heißt es Zypress? Ich bin mir grad nicht sicher.
Jan: Cypress hatte da, glaub
Garrelt: ich, verschiedene Ansätze, die alle son bisschen waren. Ist aber auch nicht, ich hab das nie benutzt. Ich weiß, hab dann nur die Vergleiche gesehen. Und Playwriter hat eben den Chromium Browser genutzt, beziehungsweise Pappettier, was ja auf Chrome basiert, was es vorher schon gab und hat da, glaub ich, noch mal 'n paar Dinge dran angepasst. Ist, glaub ich, auch von Microsoft, ne. Ich glaub, deswegen war das son Inhouse Ding, dass sie gesagt haben, hey, wir haben hier diesen coolen Browser, der headless laufen kann. Lasst den doch mal noch 'n bisschen anpassen und da dann son Testingfilmberg drauf packen. Und das hat sich als sehr erfolgreich entpuppt.
Jan: Und das war, glaub ich, son Mitteil des Erfolgsrezepts halt einfach, weil also wenn ich mich daran erinnere, wie wir ganz früher so n to n Test gemacht haben, da hast Du son 'n Selenium Server gebraucht und der Selenium Server hat dann verschiedene Browser hochgefahren und mit denen gesprochen und hat dann quasi so, war so dein dein Proxy, mit den ganzen Browsern zu sprechen so, ja. Ja. Und mittlerweile geht ja, wie Du schon sagst, nur über Papatier da halt sehr viel mehr, sehr viel einfacher. Ja. Und so wie ich das auch im Kopf hab, war halt Playright die Ersten, die das so als Bundle komplett geschippt haben, so mit, Du musst jetzt nur noch Playright installieren. Da kommt halt irgendwie alles mit drin. Mhm.
???: Du musst
Jan: nicht sich noch 37 Browser kümmern. Sie können auch ja mit anderen Browsern auch noch sprechen. Also Playright unterstützt ja auch also garantiert Firefox. Und wie das mit Webcat ist, weiß ich gar nicht, aber bestimmt auch irgendwie. Ja. Ja. Und das war dann halt schon mal so krass viel einfacher als vorher.
Garrelt: Ja, okay. Ich hab's, wie gesagt, ich hatte auch nur die Berichte gelesen und die Vergleiche, was angepriesen wurde. Und dachte mir nur so, boah, das hätt ich auch nicht gern aufgesetzt. Aber mit mit Playrite und Pubertier ist es extrem einfach, auch das aufzusetzen.
Jan: Wenn Papperier also die Browser Abstraktionsschicht sozusagen ist,
Garrelt: Mhm.
Jan: Was bringt denn dann Playrite noch alles mit? Was brauch ich denn zum zu enttesten?
Garrelt: Was braucht man zum end to end testen? Also man muss ja immer noch Tests schreiben, also 'n Test Setup. Man muss ja noch sagen, sogar mit 'n bisschen Anführungsstrichen, weil man kann auch die Tests aufnehmen sozusagen. Aber genau, was am Ende Playroad ja braucht, ist irgendwie eine Definition von, was muss ich machen und was ist mein Ergebnis? Also auch wie jeder Unit Test, man macht irgend eine Aktion und guckt sich das Ergebnis an. Und was Playroad dann eben mitbringt, ist eine schöne Schicht, das 'n bisschen zu abstrahieren. Also sie bringen zum Beispiel Lowcator mit. Also irgendeine Variante, zu sagen, okay, such mal diesen Button. Und da kannst Du natürlich entweder irgendwelche CSS Klassen nutzen, aber Du kannst auch einfach sagen, such mal den Button, wo irgendwie weiter draufsteht. Und daraus kriegst Du dann eben die Elemente, die Du brauchst für deinen Test. Und dann bieten sie dir auch schöne Funktionen an, damit was zu machen. Tipp deinen Text rein, klick da drauf, warte mal irgendwie 5 Sekunden. Und obwohl das auch relativ automatisch passiert, weil der letzte Step ist dann natürlich okay, ich hab den Button geklickt oder ich hab im Text was reingeschrieben, ich hab auf weiter geklickt und möchte dann, dass unten irgendwie steht, vielen Dank. Und dieses Warten, dass aber sich die UI updated, das machen sie auch alles automatisiert. Also sinnvolle Timeouts, dass sie darauf warten, dass die UI irgendwie auch fertig ist. Das kommt alles out of the box. Damit muss man sich eigentlich nicht mehr beschäftigen. Man sagt einfach so, wie man erwartet, dass es in der Idealwelt läuft. Und hat dann noch son bisschen Magic, irgendwelche komischen Edge Cases abzufangen, die man sich dann nicht kümmern muss. Und das Coole ist eben, es gibt mittlerweile auch eine Funktion, wo Du sagst, okay, starte mein, also ich öffne eine Webseite, starte das Recording, dann tipp ich mich irgendwie durch und er selbst macht dann, schreibt dann den Code für diesen Test sozusagen. Und dann musst Du am Ende, glaub ich, nur noch deine Erwartung definieren. Also das muss, was dann der erwartete Output ist, das musst Du trotzdem mal selber machen.
Jan: Also besteht das im Prinzip aus, ich versuch immer so mitzuzählen, was alles reingehört, ne,
Garrelt: wir haben jetzt sone
Jan: Papier für die Browserabstraktion.
Garrelt: Mhm.
Jan: Und dann bringt aber Playright selber noch sone Art Browserabstraktion oder Rapper mit, wo Du halt sagen kannst, hier führ mir dieses aus und navigier dahin und klick diesen Button und so, aber das nutzt er im Prinzip Papetier unter der Haube dann sozusagen, das alles auszuführen. Ja. Aber hat wahrscheinlich son paar Convenience Funktionen einfach schon für mich dabei, okay. Und dann ist aber auch sone Art schon mit drin oder nutzt es da auch wieder irgendwas oder muss ich das selber mitbringen. So, wenn ich jetzt sagen will, ne, ich hab hier diesen Button und jetzt will ich es sollten, dass der 'n bestimmten Titel hat oder eine bestimmte Farbe oder so was. Muss der das selber machen oder kann der das alles auch out of the box?
Garrelt: Nee, das kann der alles out of the box und soweit ich weiß, ist das auch was Eigenes, was Sie selbst geschrieben haben. Aber da bauen die bestimmt doch auf irgendwas auf, was es schon gibt. Aber man sieht jetzt nicht, also das, Du gehst wahrscheinlich auf die Zeiten, wo man irgendwie dann noch Chai und Mockka und so was alles irgendwie kombiniert wird.
Jan: Ja, zum Beispiel, ne. Also wenn ich jetzt sag, ich hab hier, weiß ich nicht, meinen, ich hab jetzt meinen Button und ich kann ja jetzt sagen, weiß ich nicht, Button Punkt title und dann weiß ich, was drinsteht und
???: dann so.
Jan: Und dann muss irgendein anderes noch nehmen, zu gucken, okay, fängt dieser Text mit hallo an? Endet der mit Welt? Passt da eine drauf? Keine Ahnung, ne. Das sind ja so diese klassischen Sachen, die man dann vielleicht irgendwie prüfen will.
Garrelt: Nee. Das bringt
Jan: ja alles mit. Das bringt ja
Garrelt: zum Glück selber mit, weil es, ich glaube, auch stark damit verknüpft ist. Weil Du sagst dann eben nicht, also was Du eigentlich im Idealfall machst, ist, wenn Du dann irgendwo was reingeschrieben hast, 'n Button geklickt hast, dann möcht ich nicht sagen, such mir mal irgendwie die Box, die Ergebnisbox und guck, ob da vielen Dank drin steht. Sondern ich sag ihm einfach, guck mal, ob jetzt auf der Seite irgendwo vielen Dank steht. Und dann sucht er sich selber sozusagen raus. Steht es irgendwo, ist das irgendwie Also das ist ja immer noch sehr eingebunden in dieses, okay, wo ist das denn jetzt in meinem Browser? Und diese ganzen Sachen willst Du ja auch bei deinen Aslsions drin haben. Und deswegen ist es da, glaub ich, viel stärker eingebunden. Und deswegen bin ich mir ziemlich sicher, dass Du da nix mitbringst, sondern das von von Haus aus kommt.
Jan: Ich stell mir dieses Feature, was Du vorhin angesprochen hast mit na ja, ich kann auch meine Tests einfach aufnehmen.
Garrelt: Mhm. Stell ich mir
Jan: auf der einen Seite supercool vor. Mhm. Weil ich seit, weiß nicht, 15 Jahren auf der Suche nach dem Tool und dem Framework bin, was nicht technische Stakeholdertests schreiben lässt.
Garrelt: Mhm.
Jan: So. Da mit mit Gerkin gab's irgendwie schon superviel und 'n Q-Covern hast Du nicht gesehen. Und das, was Du beschreibst, ist ja auch im Prinzip so, ich kann jetzt meinen Productmanager, meinen Designer, meinen keine Ahnung, was da rumklicken lassen und dir sagt, okay, so soll das funktionieren. Dann committen wir das als Test und damit ist sichergestellt, dass es halt für immer so sein wird, ja.
???: Ist ja
Jan: auf der einen Seite ganz cool. Und gleichzeitig frag ich mich son bisschen, wie sinnvoll sind denn die Tests, die da so rausfallen? Weil wenn ich jetzt sage, okay, ich hab hier eine Seite mit oder ich hab 'n Menü mit 5 Einträgen und ich tipp jetzt in meinem in meine Aufnahmesession sozusagen auf den Dritten drauf, denkt er sich dann, okay, ich muss also einfach auf den dritten Eintrag in dem Menü drücken oder ich muss auf den Eintrag drücken, der weiß nicht, Impressum heißt so, ja? Und was passiert, wenn sich das ändert? Mhm. So, bleibt er dann dabei, auf den Dritten zu drücken oder denkt er sich, ich muss auf das drücken, was Impressum heißt und wenn der Button auf einmal woanders ist, drück ich halt woanders hin. Diese diese kleinen Sachen, weil das ist ja immer so der Punkt mit diesen End zu End Test, dass die halt super unflexibel
???: halt
Jan: auch mal, je nachdem wie sie gebaut sind, super unflexibel sein können und die halt so oft auf die Füße fallen, wenn sich dein UI irgendwie 'n bisschen anpasst oder verändert oder so, dass Du dann alle Tests gefühlt nachziehen musst.
Garrelt: Mhm. Ja, ich glaube, die Frage kann man auch echt auf sehr vielen verschiedenen Ebenen beantworten oder betrachten. Also das, die eine Ebene hast Du jetzt schon angesprochen so. Wie sinnvoll sind n-to-Test über, n-to-End-Test überhaupt? Sie sind ja sehr aufwendig in der Herstellung und auch in der Wartung und da zählt das mit rein. Und dieses Problem kriegst Du dadurch natürlich nicht wirklich weg. Und genau, im schlimmsten Fall, wenn Du das über diese Aufnahmefunktion machst, verschlimmerst Du's noch. Ich glaube, ich vermute, dass ein Test, der aufgenommen wird, nicht brauchbar ist, ohne dass Du da noch nacharbeitest. Also erstens brauchst Du immer noch eine, die er so nicht von alleine hinkriegt. Also das das musst Du noch noch einfügen. Und wie konsistent er dann wirklich, was Du sagst, die Aktion macht, die Du wirklich machen willst, weiß es, ehrlich gesagt, auch nicht. Hab ich auch nicht so viel Erfahrung mit. Kommen wir auch gleich drauf zu brechen, weil wir nutzen, haben sone Handvoll End to End Tests, genau aus diesem Grund, weil die Erstellung und Wartung eben sehr, sehr groß ist. Und ich meine mich zu erinnern, dass auch einen davon mal aufgenommen hab. Aber das nutzen wir am Ende nicht so viel. Und ich vermute so dieser Use Case so, ja, das da da klickt dann irgend Manager oder wer auch immer rum und Du hast am Ende 'n Test, den Du einfach laufen lassen kannst. Das wird so in meinen Augen nicht funktionieren. Also ist überhaupt fragwürdig, ob das so viel Sinn ergibt, weil dann hast Du am Ende vielleicht die Aktion, die er gemacht hat. Aber dann weißt Du immer noch nicht, was jetzt seine Erwartung an welcher Stelle war. Dann musst Du's wahrscheinlich aufnehmen, was er macht. Dann soll er das dazu sagen, dann kann's wahrscheinlich am Ende besser selber machen. Aber wenn Du derjenige bist, der ihn schreibst, dann ist das auf jeden Fall 'n extrem guter Startpunkt, diesen Test zu erstellen.
Jan: Okay, dann lasst uns doch mal darüber sprechen, wie ihr das nutzt. Ihr habt bestimmt 100 Prozent Code Coverage mit euren End zu End Tests mit Playrite.
Garrelt: Auf gar keinen Fall. Weit, weit entfernt. Aber also, aber warum nicht? Weil es, gute Frage. Also ich sag mal, das Hauptproblem für mich bei Test ist eigentlich das Set-up. Also es überhaupt hinzukriegen, dass es läuft. Also wir haben ja wir haben ein Spiel, was in in Facebook läuft, also in Facebook instinc Game ist. Und allein da das Set-up hinzubekommen, dass er wirklich in dieser realen Situation ist, dass er in dieser die Facebook API hat, in dieser Sandbox ist, dass er eigentlich lebt wie in Facebook, die kriegst Du schon, wenn überhaupt, mit sehr, sehr viel Aufwand nur hin. Also das Aber
Jan: das könnte man ja wegmocken.
Garrelt: Das könntest Du wegmocken, ja, aber auch das ist viel Aufwand. Also das das erst mal aufzusetzen, ist sehr aufwendig und deswegen haben wir's gar nicht gemacht. Sondern wir haben unseren Partner, also unser Spiel lebt ja auch in Native und da hast Du keine Sandbox. Das ist einfach eine Webanwendung, die Du auch im Browser laufen lassen kannst, die dann halt als App verpackt ist. Das haben wir genutzt, end to end Tests, also richtige end to end Tests zu machen, wo jemand was rumfliegt. Und das ist, war uns gut genug, weil die Bar, die Codebasis die gleiche ist wie bei Facebook auch. Aber das war schon mal ein Grund, warum ich definitiv sagen kann, wir haben nicht alles abgedeckt, weil eben viele von den facebook spezifischen Sachen da überhaupt nicht mit reinspielen. Selbst wenn Du's moggst, Du, also diese ganze Facebook UI, die da noch mit reinkommt, die hast Du ja dann nicht, also die kannst Du ja gar nicht abdecken. So und das seh ich auch irgendwie als Teil der App.
Jan: Und wir haben ja schon gesagt, dass End zu End Tests in im Schreiben schon 'n bisschen teurer sind, weil Mhm. Das aufnehmen muss. Irgendwie gucken, dass deine ganzen Targets und Pfade, die Du irgendwie adressierst, irgendwie einigermaßen stabil laufen. Aber sie sind ja wahrscheinlich auch relativ teuer in der Laufzeit.
???: Also
Jan: Mhm. Weil das weiß wahrscheinlich besser Erfahrungsfeld bei euch so, wie lange laufen so alle eure Unit Tests
???: Mhm.
Jan: Versus wie lange braucht's, alle eure End zu End Tests laufen zu lassen?
Garrelt: Deutlich Sänger. Also ich kann ja mal noch konkreter sagen, wie unser Set-up ist. Also wir haben eben, ich würde sagen, sone Handvoll 5 Stück von diesen klassischen End to End Test, wo irgendwer sich durchklickt, es 'n User erstellt wird, am Ende wird er wieder gelöscht. Und der viel größere Part und auch wichtige Part für uns ist die Visual Regression Tests, die wo man auch irgendwie vielleicht sogar fragen könnte, ist das wirklich 'n End to End Test? Aber es ist halt auch nur mit sonem Set-up möglich. Was ist das? Genau, Visual Recussion Test ist eben, dass man die App irgendwie in einen bestimmten State bringt, zum Beispiel auf einen Screen, dann 'n Screenshot macht im ersten Step. Und wenn man's dann noch mal macht, eben diese Screenshots miteinander vergleicht. Und dadurch kann man irgendwie sehen, okay, da hat sich irgendwie eine Komponente verändert, die sich gar nicht verändern soll. Das ist eigentlich so der typische Use Case davon. Das heißt, wenn man irgendwas refact hat, aber nicht auf dem Schirm hat, dass irgendwie diese Komponente auch noch auf dem und dem Screen lebt, dann soll das abfangen, dass man da nichts ungewollt ändert. Und das war bei uns deutlich einfacher, weil wir sonen Playground haben, also einfach eine, im Prinzip noch eine dritte App, die nur für uns als Entwickler ist, wo wir jeden Screen, den wir entwickeln, noch mal einzeln auf eine Seite packen, sodass wir in bestimmte Cases, die schwerer zu erstellen sind, in der App viel einfacher testen können. Und das haben wir uns eben zunutze gemacht, diese Screens dann zu screenshotten und damit abzudecken, okay, die sollen sich nicht verändern. Und das sind vielleicht dann irgendwie, keine Ahnung, 300 Stück oder so. Oder 'n bisschen mehr, vielleicht sogar 400. Und die, das ist der größte Teil an diesem, wenn die Test laufen und das dauert schon extrem lange. Also Tests, ich müsste nachgucken. Ich denke, irgendwas zwischen ein und 2 Minuten. Und die Tests laufen auch schon gerne mal irgendwie 10 Minuten oder so was.
Jan: Und da sind aber die Tests mit drin.
Garrelt: Da sind die mit drin. Da ist alles mit drin, genau.
Jan: Dann ist das ja für 'n paar 100 Screenshots auch okay.
Garrelt: Es ist in Ordnung. Es ist in Ordnung, aber es ist trotzdem am Ende das, worauf man wartet, So. Alle anderen Sachen sind halt sehr schnell fertig. Und grade wenn's mal schnell gehen muss, nervt's schon auch manchmal darauf zu haben.
Jan: Und dieses Visual Requestion Testing, das ist auch in Playrite mit drin oder nutzt ihr da nur Playrite und macht dann den eigentlichen Vergleich mit irgendwas anderem?
Garrelt: Nee, das hat auch genauso mit. Das nutzt einfach, diesen Screenshot zu machen und, also Du merkst am Ende nix von, aber bietet diese Funktion, Screenshots zu machen von diesem von diesem Tab, also von dem
Jan: Von dem Fenster. Was auch was,
Garrelt: danke. Trotz, dass es eben Headless ist, das find ich immer wieder cool irgendwie daran, dass Du gar keinen Browser offen hast, aber er kann dir trotzdem Screenshot machen. Genau. Und Playlight macht dann eben diesen Pixelvergleich, da kannst Du auch noch 'n paar Settings machen, wie sensibel der jetzt ist.
Jan: Das wär jetzt nämlich meine Frage gewesen. So, wie oft fällt das auf die Schnauze? Weil natürlich grade, wenn man jetzt so auf Pixelebene vergleicht, das ist ja zwar 'n sehr genauer Vergleich, aber auch gleichzeitig 'n sehr stupider. Ja. So, weil wenn jetzt, weiß nicht, Du machst vielleicht 'n Browserupdate oder 'n Betriebssystemupdate und dann ist auf einmal dein irgendwie 'n bisschen anders oder so was, ja. Oder es muss sich ja vielleicht nur irgendwas in der Kompression von dem Screenshot verändert haben, ne, ohne dass Du irgendwie inhaltlich was was getan hast und schon stimmen irgendwie die Pixel ja nicht mehr 1 zu 1 überein. Das heißt, habt ihr da son so son Schwellwert oder gibt's da sone Toleranzgrenze oder wie verhindert ihr, dass er gefühlt bei allem sagt, es hat sich was getan? Ich bin immer wieder überrascht, wie gut Du dich mit diesen Dingen auskennst. Also Du hast
Garrelt: so ein breites, aber auch Ich
Jan: dachte, meine ich, hast das schon mal gemacht, ne?
Garrelt: Ja, ist ja, also ja okay. Dann können wir das auch
Jan: einfach schon mal gemacht.
Garrelt: Ja, ich mein, Du hast ja auch eben erzählt, dass er das früher auch mit Selenio gemacht hat. Aber Früher vorm Krieg haben wir das
Jan: ganz anders gemacht, Garre. Da musst Du uns das Spielplatz auch selber machen.
Garrelt: Ja, also Toleranz. Ja, genau. Du, also ja, absoluter Punkt. Man muss das 'n bisschen twegen, aber wir haben irgendwann eine Einstellung gefunden, die fein für uns ist. Und klar, es kommt dann schon mal vor, dass wenn man 'n Update macht, der dann noch mal bei 'n paar bei 10 Screenshots sagte, hey, die haben's geändert. Und dann guckst Du kurz drauf und updatest die und dann ist gut. Also diesen Prozess, dass er dir sagt, jetzt hat sich was geändert und es ist aber 'n volls Positiv. Kommt schon manchmal vor, ist aber auch nicht so dramatisch. Also ich guck mir lieber die an und hab die immer mal wieder und update die dann, ohne dass was falsch war, als es nichts zu haben, weil es einfach diese Sicherheit gibt, dass wenn dann doch mal was kaputtes, man das sonst nicht entdeckt. Und das kommt nicht so häufig vor bei uns.
Jan: Wie muss ich mir das vom Workflow her vorstellen? Weil im Prinzip, wenn ich jetzt 2 Bilder vergleiche, okay, ich kann das auf Pixelebene irgendwie machen.
???: Mhm.
Jan: Aber das ist ja erst mal 'n sehr synthetischer Diff, der dann da rausfällt, so. Mhm. Wie wird das repräsentiert? Mhm. Wie wie seh ich das auf einen Blick, dann halt einordnen zu können, okay, da ist jetzt nur, ne, am Rande von den Buchstaben irgendwie was, dann wird das 'n Körning Problem sein oder gibt's da son sone Ergebnisansicht oder 'n Report oder wie zeigt er dir, was da rauskommt bei dem Visual Regressive?
Garrelt: Ja, das ist das ist echt 'n guter Punkt, weil ich glaube auch, dass das ein Erfolgsfaktor von Playroad ist, weil das machen sie verdammt, verdammt gut. Nicht nur für die Screenshots, sondern auch für die Tests. Also Du hast eben sone Reportseite, die Du bekommst, wo dann alle aufgelistet sind und die Falschen eben gehighlightet sind. Und wenn Du draufgehst, dann zeigt er dir verschiedene Varianten an, wie Du das angucken kannst. Ich glaub, die Standardvariante ist eben, dass er dir den Screenshot zeigt und da, wo sich was verändert hat, die Pixel rot sind. Mhm. Und dann kannst Du's mit 'nem Slider machen
Jan: Die div so massiert sozusagen.
Garrelt: Diff maskiert. Dann kannst Du entweder mit 'nem Slider dir die Unterschiede angucken oder Side by Side. Das ist verdammt gut gemacht. Also da sieht man sehr schnell, was Und das ist bei euch
Jan: in der CI mit drin. Das kriegst
???: Du in
Jan: deinem Pool request angezeigt oder Genau. Wie kommst Du denn da hinten?
Garrelt: Genau, er packt einfach 'n Kommentar in den, wo dann 'n Link zu diesem Report ist. Und der diese CI Pipeline sagt dir dann, entweder ist fehlgeschlagen, dann guckst Du halt rein oder ist ein alles grün, dann machst Du's nichts. Und eigentlich ist aber fast das Coolere ist, wie sie dir anzeigen, die eigentlichen End to End Test, die Du die Du machst. Und zwar hast Du da, siehst Du da eben auch 'n Bild von deinem, oder im Prinzip sone Art Video von deiner App in dem Browser und Du hast eben sone Timeline. Und dann kannst Du genau von Anfang bis Ende, ich weiß gar nicht, in welchem Abstand es geht, aber jede Sekunde oder jede Aktion auch, kannst Du genau da hingehen und sehen, was ist denn hier grad passiert? Und wenn er dann fehlschlägt, dann kannst Du halt wirklich alles genau nachverfolgen, welche Aktion hat er gemacht? Warum ist da an der Stelle nichts passiert? Und das machen sie verdammt gut. Also das kannst Du dir lokal gut anschauen, aber in dieser in diesem Report, in der CI Pipeline eben auch. Und das hat mir vor allen Dingen bei der Erstellung auch sehr viel geholfen, weil eben dieses Setup oft Probleme macht. Und es läuft ja nicht auf deinem Browser, sondern irgendwo Headless. Und damit kannst Du's aber immer sehr gut nachvollziehen.
???: Mhm.
Jan: Du hast ja am Anfang auch schon so eure dritte App erwähnt, wo ihr euch die Views so zusammen konfigurieren, zusammenmocken könnt, da son paar kleinere Tests drin laufen zu lassen. Das macht ihr aber nur für ganze Views, also für ganze Screens sozusagen, ne?
Garrelt: Nee, wir haben auch angefangen, dann eben einzelne, also Screens zu machen, einzelne Komponenten in ihren verschiedenen Ausprägungen noch mal zu machen.
Jan: Das wär ziemlich genau meine Frage gewesen, wenn ich jetzt nur eine einzelne Komponente hab und die testen will, bringt da auch schon so was mit, wo ich einfach nur sagen kann, okay, ich hab hier eine, weiß ich nicht, eine Komponente, kannst Du die auf sone Blanko Seite injecten und hier sind son paar Parameter und ränder die mal? Oder muss ich mir da selber so quasi behelfen und son bisschen 'n Debug Rapper drum rum bauen, in der das dann hosten kann?
Garrelt: Das musst Du selber machen. Also zumindest wüsst ich nicht, dass Playwriter das mitbringt. Das ist ja für mich eher so auch dieser Storybook Ansatz.
Jan: Ja, genau.
Garrelt: Ich frag mich ich frag mich grade, weil ich mich da einfach nicht mit beschäftigt haben, hab, ob die, also ob Playwriter und Storybook zum Beispiel eine Integration haben, die so was Verfügung stellen, könnt ich mir gut vorstellen, dass die so was machen. Mhm. Dass Du sagst, hey, guck mal, Playright, hier ist mein Storybook. Mach bitte mal Visual Regessen Test von allen möglichen. Das könnt ich mir vorstellen, aber Also falls
Jan: uns jemand von Storybook zuhört Ja. Jetzt. Das ja, das Einmal hier E-Mail an Podcast at Programmier Punkt com.
Garrelt: Ja. Aber wir, genau, wir mussten das manuell machen. Aber ich glaub, sonst bräuchtest Du ja sone View, zum Beispiel eine Viewintegration, wo Du sagst, hier meine View Komponente, das sind meine Parameter oder sieht er dann selber. Aber das wüsst ich nicht, dass es das gibt.
Jan: Okay. Und das heißt, ihr habt euch das jetzt quasi gebaut und das funktioniert dann so, dass Du halt sagen kannst, okay, hier ist meine meine View oder meine Komponente. Du vorkonfigurierst die quasi als der von deinem Test Bootstrapping und dann läuft da einfach Playright drüber und kannst deine Östions da drum klicken und machen und tun. Oder halt nur 'n Screenshot machen, wenn das Ja,
Garrelt: genau. Das so, ja.
Jan: Genau, also
Garrelt: wir haben diese Drittapp, die für uns ist, damit machen wir rein diese Test und nutzen dann die Variante für, die eigentlichen n to s end to end Test zu machen.
Jan: Weil wir grad wieder bei Screenshot sind, wir haben ja auch krass viele Animationen. Mhm. Testen wir das auch mit so was?
Garrelt: Das wär
Jan: vielleicht noch schwieriger folgen.
Garrelt: Ja, das ist auch schwierig. Ich wüsste auch gar nicht, kann mir nicht vorstellen, dass das irgendwie sinnvoll geht, die sind alle. Also Animations, Timeouts und so was, das musst Du alles son bisschen anpassen. Aber da war das Set-up relativ überschaubar. Sodass eigentlich random musst Du anpassen, Timeouts musst Du irgendwie direkt auflösen und CSS Animations ausmachen und Transitions ausmachen. Und ich glaub, das war's. Also das hat gereicht, genau, diese Animation auszustellen, damit Du die Screenshots sinnvoll machen kannst. Aber testen, boah, bin ich mir gar nicht sicher, ob's da was gibt für. Ich glaube schon, aber nicht im Playrad, glaub ich. Okay.
Jan: Wenn ihr diese ganzen Visual Regation Tests machst, musst Du ja irgendwo die Screenshots auch lagern, gegen die Du immer wieder vergleichst.
Garrelt: Mhm.
Jan: Sind die Teil von dem Repository bei euch dann einfach? Weil das ist ja schon wahrscheinlich nicht wenig so und ich ich hab mir ja sagen lassen, insbesondere früher, ich weiß nicht, wie das aktuell so ist, aber gibt es ja nicht son Freund von großen Datenmengen ins Repository. Und grade, wenn Du jetzt sagst, bei 400 Screenshots und die ändern sich ja auch ab und zu, ne, da kommen ja schon, also wahrscheinlich gigabyteweise Zeug zusammen, oder? Gute Frage. Also ja, die leben in der in der Repo.
Garrelt: Und ich versuch es grad mal zu finden, Snapshots. Also es sind 620 Objekte sogar, krass, ich vermehrte Kräfte, aber am Ende sind's 113 m b
Jan: im jetzigen Zustand. Aber das ist ja auch die gesamte Historie von allen Screenshots auch mit drin. Also das Report wird ja dadurch Hunderte Megabyte wahrscheinlich größer werden.
Garrelt: Das stimmt. Das ich weiß gar nicht.
Jan: Also ihr musstet noch, also die die Frage war eigentlich mehr so, ihr musstet jetzt noch nicht auf irgendwie Git large File System oder so was migrieren, weil euch das irgendwie Probleme gemacht hat.
Garrelt: Nicht, dass ich Weil das
Jan: sone Sorge, die man halt häufig hört, ne. Aber wenn das noch keine Schmerzen verursacht, dann ist es vielleicht auch gar nicht so schlimm am Ende des Tages.
Garrelt: Ich weiß aber halt auch nicht, was wir da, also was das fürn Company, was wir da fürn Plan haben bei GitHub? Vielleicht ist der schon so groß, dass das keine Rolle spielt. Aber ich hab, also ich hab mich noch nie damit beschäftigt. Es war auch noch nie Thema. Und deswegen würd ich entweder sagen, haben wir da schon großzügige,
Jan: ja, von der Kota wird das schon passen.
Garrelt: Ja. Nice. Ich wüsste auch gar nicht, wo man das nachguckt,
Jan: was ich sagen. Was, wenn jetzt jemand zuhört da draußen und sich denkt so, boah, das klingt alles voll cool. Was braucht ihr denn, damit anzufangen? Wenn ich jetzt sag, so ich hab hier schon meine meine kleine Web App oder eine Webseite oder irgendwas, ich will jetzt auch Playright machen. Wie wie kann der am einfachsten starten oder Sie?
Garrelt: Na ja, also für mich ist dieses, also die erste Frage, die ich mir immer stelle, ist so, also ist für mich immer die erste Frage, braucht man das? Also möchte man, was hat man davon?
Jan: Garnit Morg Quality Beauftragter, weil der Frau kam.
???: Also ich
Garrelt: mein, ich hab's ja bei uns eingerichtet so. Offensichtlich hab ich mir gedacht, okay, es wäre sinnvoll für uns. Aber ich finde, es ist, man muss immer abwägen, wie viel Kosten Nutzen abwägen. Also wie viel Aufwand ist das einzurichten? Wie stabil ist das Projekt? Dass grade End to End Tests sind halt sinnvoll, wenn sich da auch nicht so viel ändert oder auch nicht so viel ändern soll oder es zumindest Bereiche gibt, wo's stabil ist. Wenn man jetzt in 'ner frühen Phase ist, ja, macht auf gar keinen Fall Tests. Deswegen, ich glaube, ich find's bei Tests immer wichtig, mich damit zu beschäftigen, so, was bringen mir die? Und gehe ich sozusagen bewusst ein, dass es halt auch Aufwand mit sich bringt, die zu pflegen. So, das ist das Erste, was ich mich irgendwie immer frage. Und ansonsten ist in Playrate Reinkommen wahrscheinlich 1 der leichtesten Dinge überhaupt. Es ist am Ende 'n MPM Package, was man sich installiert, was automatisch die ganzen Browser installiert, die Du dafür brauchst. Und ich war jetzt schon länger nicht mehr auf der Playright Seite, aber ich weiß, dass sich's wirklich nicht lang gebraucht hat, da irgendwie mal den ersten Test laufen zu lassen. Und am Ende, glaub ich, ist die größte Hürde, die man nehmen muss, sein Set-up da einzurichten. Also eben dieses, okay, meistens hast Du irgendwie 'n Log in. Wie schaffst Du's, in Playwrites zu konfigurieren, dass Du da 'n User hast, dass Du überhaupt Dinge machen kannst? Und ich glaub, das ist der größte Aufwand, den man auch nicht generell beantworten kann. Das muss man eben individuell machen. Aber da bietet auch Playwrit, die kennen das ja genügend Optionen, son Tierdown heißt das runterfahren, also son Skript, das dann am Ende läuft, deinen User wieder zu löschen oder was auch immer. Und wie heißt 'n das? Boot-up heißt das? Oder Boot-up?
Jan: Boot-up oder Set-up oder so was?
Garrelt: Ja, oder Set-up vielleicht sogar, genau. Was Du halt irgendwie vor deinen Tests laufen lässt, irgendwie 'n User zu erstellen.
Jan: Aber das ist ja im Prinzip auch keine keine revolutionär neue Aufgabe, so. Das muss ja bei jedem anderen Integration Test irgendwie auch machen.
???: So, also
Jan: wenn Du dir schon mal grundsätzlich Gedanken darum gemacht hast, wie schaffst Du sone reproduzierbare Testumgebung irgendwie hoch- und runterzufahren, Ja. Dann hast Du auch alles, was Du für Playwriter irgendwie brauchst.
Garrelt: Weiß es nicht. Also gut, ja, vielleicht schon.
Jan: Weil wenn ich jetzt, ich sag mal, mal meine API automatisiert testen will, weil ich da son bisschen mit Köln dagegenwerf oder so was. Ja. Da muss ja auch irgendwas in der Datenbank sein, ne, was irgendwie wiederkommt, was da ist, was Voraussetzung ist, was ich deterministisch irgendwie vorhersagen kann, wie es sich verhält und so was alles. Genau dasselbe ist es ja dann bei so Playwrit und End zu End Tests im Prinzip auch. Ich muss dafür sorgen, dass Ja. Mein User da ist. Ich muss dafür sorgen, dass son paar Mog Daten in der Datenbank sind, weiß nicht, in meinem CMS muss eine Seite angelegt sein oder in meinem Bahnwirtschaftssystem 'n paar Produkte oder so was, auf die ich dann rumklicken kann.
Garrelt: Ja, ich glaub, das Einzige, also ich hab halt grade drüber nachgedacht, wir haben, Integration Tests in unserem Backend waren ja schon da, die haben mir halt nur nichts gebracht. Also dieses Set-up konnt ich jetzt nicht nutzen, das Set-up im Frontend zu machen. Weil wenn Du's in deinem Backend machst, da kannst Du ja das Backend und die ganzen Datenbanken lokal laufen lassen. Wenn Du's aber mit deinem Frontend machst, war aber jetzt bei uns es nicht so, dass wir gesagt haben, okay, wir lassen dafür jetzt auch das Backend noch mal lokal
Jan: Könnte man
Garrelt: ja aber machen. Könnte
???: man machen.
Garrelt: Gut, bei uns war das
Jan: Set, also Also ehrlicherweise, jetzt jetzt stell ich mal hier die ketzerische Frage. Wer sagst, Du willst 'n echten End zu End Test haben, ne, weißt Du, vom vorderen Ende bis zum hinteren Ende, Ja. Dann könnt ich behaupten, Du musst vielleicht sogar dein Backend mit hochfahren. Weil nur dann ist es 'n echter End zu
Garrelt: End Test. Also wir haben halt unser Dev Backend genutzt dafür. Und dann ist vielleicht so die Frage, ist das näher an der Realität, weil das dann auch noch in der Cloud läuft? Also ja, ich glaube, wahrscheinlich, vermutlich ist es dann Monorape auch wirklich sehr stark, ne, weil Du dann auch einfacher sagen kannst, okay, dein Setup bedeutet halt auch, dass Du dein Backend hochfährst. So, das ging bei uns nicht so einfach.
Jan: Das heißt, das Backend bei euch sozusagen ist quasi ein eine gescherty Cloud Instanz, gegen die ihr alle arbeitet, wenn ihr lokal das Frontend entwickelt, oder was? Nee, also lokal machen wir auch das Backend oft lokal.
Garrelt: Okay. Ist noch mal so für genau diese Szenarien oder wenn man auch mal was mit der Cloud testen will, also wie das wie das Backend sich in der Cloud verhält sozusagen. Also das ist ja einfach noch mal sone Instanz für ein paar User Cases, die wir haben.
Jan: Aber ihr fahrt für eure Playrites, die i-Tests kein dediziertes Backend hoch. Nein.
Garrelt: Okay. Das läuft, genau. Das ist das der Prägung, was schon läuft.
Jan: Okay. Okay, und das heißt natürlich auch, dass wenn Du jetzt quasi anfängst, was zu testen, Du kannst dir ad hoc in soner Set-up Methode zwar einen User einrichten, sagen, okay, ich erstell mir jetzt 'n User und ich kann vielleicht auch stimmen, wie der heißt, aber ich kann zum Beispiel nicht vorhersagen, was für eine ID der bekommt.
Garrelt: Ja. Richtig.
Jan: So, und da wird's dann son bisschen Das schwammiger.
Garrelt: Genau, das war 'n bisschen schwammig. Und ich glaub, also deswegen hatten wir auch das Dev Backend, weil da mussten wir dann sozusagen auch implementieren, dass dieser User, der von erstellt wird, auch 'n Testuser zum Beispiel ist. Und das soll natürlich auf gar keinen Fall in der Pod Umgebung gehen. Dafür musste man das Devbackant 'n bisschen einrichten. Aber das Coole ist eigentlich, das Set-up bei uns, also dieses User erstellen, ist wirklich auch wie 'n End to End Test, weil er macht am Ende, erstellt er den User über die UI sozusagen. Das fand ich eigentlich das Coolste daran, dass Du nicht sagst, mein Set-up
???: ist Also
Jan: dein dein End to End Test fängt sozusagen an, indem sich playride anmeldet in der App, wie als wäre 'n Richtig. Fast Time User sozusagen. Richtig.
Garrelt: Und am Ende, der letzte Test, der Tierdown ist im Prinzip auch 'n Test, dass er in die App geht, an die Stelle, weil ich da ist er löscht. Das ist eigentlich ganz cool da rein.
Jan: Ah ja. Ja, okay.
Garrelt: Das hat das hat mir, also dass das ging und dass ich das so aufsetzen konnte, dass das auch 'n Test ist und nicht nicht irgendwelche, keine Token, Token mir irgendwo kopieren muss oder was auch immer.
Jan: Das bringt mir auf eine andere Frage, wenn's die Architektur von End to End Tests geht. Mhm. Wie gesagt hast, Du musst dich quasi anmelden für deinen Test.
Garrelt: Mhm.
Jan: Und am Ende meldest, also nicht meldest Du dich wieder ab, sondern löscht deinen Benutzer quasi wieder. Und wenn ich jetzt 5 n zu n Tests hab,
???: Mhm. Weil
Jan: ich 5 verschiedene Szenarien, 5 verschiedene Flows, keine Ahnung, was testen will, da muss ich mich ja fünfmal an- und abmelden. Sonst also fünfmal den User erzeugen. Ja. Wie findet da die Balance zwischen, na ja, wir können ja alles in einen sehr großen End to End Test machen, weil da haben wir schon den User angelegt und wir können einmal, ich weiß nicht, was ihr alles testet, ne, wir können einmal so den testen, wir können einmal das testen, wie er das ausmacht, wir können einmal den Shop testen, whatever so. Das können wir alles in derselben Session machen. Mhm. Versus, lass uns das in getrennte Flows legen, weil's vielleicht sauberer ist, weil sie jeweils kleiner und übersichtlicher bleiben. Aber dafür hast Du halt jedes Mal wieder mehr Overhead für, ne, ich muss mich halt jedes Mal wieder neu anmelden und den User auch am Ende wieder wegräumen. Wie macht wie macht ihr das?
Garrelt: Ist 'n guter Punkt, weil das auch noch ein Thema betrifft, was wir noch ganz angesprochen haben, ist die Parallelität bei den Tests. Also Du kannst sehr gut nutzen, parallel Tests laufen zu lassen und eben auch genau diese Tests. Und genau dann musst Du dich eben fragen, wenn grade wenn ich sie parallel laufen lasse, mach ich das auf demselben User oder sollten die anderen eigenen haben? Oder wie gesagt, sollte jeder Test 'n eigenen bekommen? Wir haben uns jetzt eben dafür entschieden, dass wir einen erstellen, dann diese 5 End to End Tests machen, die wir haben, aber die auch so gewählt sind, dass die kaum verändern, der jetzt irgendwas kaputtmachen könnte. Das heißt, ihr
Jan: legt einmal den User an, dann laufen 5 parallele Tests los und dann wird am Ende wieder aufgeräumt.
???: Mhm. Und
Jan: das heißt, wie muss ich mir das vom Set-up her vorstellen, dieses User anmelden? Ist es dann sozusagen ein Ministest, der den anderen vorgelagert ist oder ist das Ah, okay.
Garrelt: Der ist Blocking, also das die ganze Testsuit, also die eigentliche, dieses Wort ist schwierig für mich, suit, die ganze Testsuit, wartet darauf, dass dieses Setup passiert und fängt dann erst an.
Jan: Okay, es heißt ein Setup für alle Tests. Ja. Und die Tests jeweils für sich haben dann kein eigenes -up mehr sozusagen. Kannst Du auch machen. Okay. Also ich kann quasi ein Set-up auf suitebene suite Ebene definieren und auf Einzeltesterbene noch mal. Ja, richtig. Und dasselbe beim Abbauen
Garrelt: wahrscheinlich auch.
Jan: Richtig. Ah nice, ja. Okay. Und die anderen laufen dann parallel, weil gemeinsamer State kein Problem ist an der Stelle.
Garrelt: Genau. Beziehungsweise ich müsst dir kurz überlegen, Du definierst, wie viele Prozesse laufen und dann
Jan: Ja, das scheint mir son Performance Ding, ne, dass Du sagen kannst, maximal 3 parallel oder so was.
Garrelt: Genau, aber dann laufen eben alle alle Tests, die Du definierst in diesen 3. Und ich glaube, die 5 End to End Tests, die wir da haben, laufen in einem, weil dann noch, sag ich mal, 100 Screenshottests in demselben laufen Ah. Und der nächsten 100 in dem anderen Prozess. Ich glaub, so ist das bei uns. Ich glaub, die 5 sind tatsächlich doch in einem. Und dann laufen aber vor allen Dingen die
Jan: Gut, aber wenn die anderen Screenshots so lange brauchen, ist das ja dann auch wieder Ja, ja. Egal sozusagen. Ja, ja. Okay. Okay. Wie Jetzt haben wir son bisschen darüber gesprochen, wie's funktioniert, wie's aufgebaut ist. Wie einfach ist es, da reinzukommen? Lass uns, ich sagte, das Pferd hier von hinten auf ist vielleicht nicht so vorteilhaft, aber lass uns noch mal 'n Schritt zurück hin so. Mhm. Wie war die Diskussion im Team zu, wollen wir das, brauchen wir das, lass uns das mal machen. Ja, oder gab's da noch mehr Leute, die gesagt haben, 'n Test sollte man uns mal überlegen, ob man das überhaupt braucht?
Garrelt: Ja, das gab's auch. Also das gibt's, glaub ich, immer. Und meistens bin aber auch ich die Person, die sagt, so brauchen wir das so unbedingt?
Jan: Ist das ein Test oder kann das weg?
Garrelt: Ja, zu Test hört man, find ich's auch, aber auch immer wirklich spannende und teilweise sehr unterschiedliche Takes. Also auf der hat das 'n Vortrag, wo sie meinte, ja, meistens hat man viel zu viele Tests und viele Tests sind auch unnötig. Also war so die Hausaufgabe, weil
Jan: die Leute gerne viel testen, aber nicht unbedingt das Richtige.
Garrelt: Ja, genau. Und dann war so die Hausaufgabe, geht mal
???: nach Hause und löscht
Garrelt: mal einen Test aus, also von einem Produktchen quasi, ich war so. Dann hab ich das son mitgebrachtes Team und alle waren so, Alter, mach das auf gar keinen Fall. Also ja, sehr viele, genau, sehr viele unterschiedliche Meinungen, deswegen ist das, glaub ich, immer 'n sehr schwieriges Thema. Wir haben bei Lotum coolerweise son Konzept, das nennt sich Personal Growth Day, was Du bestimmt schon gut kennst. Und das ist so einmal im Quartal, einen Tag, wo man sich zu irgend 'nem Arbeitszimmer fortbilden kann. Und da war eben Und
Jan: das Arbeitsthema ist da ehrlicherweise auch sehr weit definiert.
Garrelt: Sehr weit definiert, was es aber auch immer sehr cool ist.
Jan: Ja, ja, will will nur sagen, es ist nicht so, dass Also ich glaub, manchmal Leute machen das auch, aber ich versuch immer, die dann da son bisschen zu piesacken dafür. Es ist nicht dafür gedacht mit, nimm dir mal einen Tag und mach die Arbeit, die liegen geblieben ist und wofür Du sonst keine Zeit hast.
Garrelt: Nee, nee. Das zum Glück nicht. Weil auch das
Jan: hab ich schon erlebt in anderen Firmen so. Wir machen jetzt hier so einen Aufräumtag oder so. So, nein, das ist nicht so, sondern das ist schon so, mach mach was, worauf Du Bock hast.
Garrelt: Ja, mach und mach, es muss ja irgendwie mit der Arbeit zu tun haben und ich mach mir immer 'n bisschen Spaß daraus zu gucken, wo die Grenzen wären. Also könnte man argumentieren, dass ich Sport machen muss, weil ich mit dem Fahrrad zur Arbeit fahre und dann bildet man sich
Jan: Also ich glaube, wenn Du hier ankommen würdest und sagen würdest, ich mach am Yoga, wenn wir den ganzen Tag am Rechner und am Schreibtisch sitzen, dann
Garrelt: wär das verständlich
Jan: Niemand würde was sagen.
Garrelt: Ja, ne, sag ich ja. Niemand. Das find ich das find ich spannend daran.
Jan: Aber das ist, das ist eigentlich echt eine coole Idee, das mal so ganz, so für sich so zu unterwandern, ja, diesen Tag so. Immer immer weiter zu gucken, so, wann wann sagt eigentlich jemand was oder wann?
Garrelt: Beim letzten Person of the war meine Scherzidee, dass ich's ja mal testen könnte, was die Viertagewoche mit mir macht. Und Und
Jan: am Ende, ich glaub, das reicht noch nicht, hier irgendwie für die Alarmglocken wahrscheinlich's nicht. Obwohl's, glaub ich, schon, ich glaub,
Garrelt: da hätt ich's was gesagt bekommen. Na, auf jeden Fall waren früher, also als ich bei Löschhop angefangen hab, meine Ideen noch nicht so frei, sondern da hab ich gedacht, oh, machen wir mal Play Ride, weil ich das interessant fand und eben auf der Konferenz auch gehört hab. Und hab halt einfach mal angefangen, son Set-up damals dann vor allen Dingen erst mal für diese Visual Visual Repression Test zu machen, weil da das Set-up einfacher war. Und dann hab ich das auch, ich erinner mich, dass ich das so grade so hab aufgesetzt bekommen, hab das dann so in meinem Team gezeigt. Und es war, es war wirklich nicht reif oder fertig, aber es hat halt irgendwas gemacht. Und dann haben wir gesagt so, ja, lass es uns einfach mal einbauen und gucken, also laufen lassen in der SI und gucken, ob es uns irgendwas bringt. Ändert sich das Gefühl beim Entwickeln? Haben wir irgendwie mehr Sicherheit? Und haben das gemacht. Und ich glaub, lustigerweise bin ich dann auch in die Elternzeit gegangen und hab dann nur am Ende mitbekommen, dass sie das dann für gut empfunden haben und es rechtlich aufgesetzt haben. Und als wiederkam, lief das dann
Jan: Das ist natürlich auch 'n Hacklicher Typ.
Garrelt: Ja, ja, genau. Hier Zum Beispiel die
Jan: die Idee ist Ja,
???: ja, ich
Jan: bin jetzt erst mal 'n paar Monate weg. Schaut doch mal, dass ihr das fertigkriegt.
Garrelt: Ja, aber sie haben sich nicht beschwert. Also ich hatte das Gefühl, dass der, der's gemacht hat, dann auch Spaß damit hatte. Aber ich glaube, ich glaub mal, das
Jan: ist auch son sehr visuelles Thema und ich glaub, das hilft immer da son bisschen Begeisterung für zu bekommen.
Garrelt: Ich denk auch, ja. Ich glaub schon. Und das war halt wirklich son sweet Spot von, es ist jetzt nicht so aufwendig, also 'n Visual Reggasten Test Set-up ist wirklich relativ einfach, wenn man eine App, also wenn man wie uns Aber weil
Jan: ihr halt euer euer eure Sandbox da schon
Garrelt: Ja, ja, genau. Sagt.
Jan: Ne, ich glaub, das ist tatsächlich für die meisten an der Stelle der größte Aufwand. Ja. Nicht so, ne, ich mach jetzt hier 600 Screenshots und dann vergleich ich die bis zum seit Nippelleins Tag, sondern wie krieg ich überhaupt meine App in den State, dass ich halt ad hoc diese 600 States jederzeit wieder aufrufen kann. Ja. Und das nicht viel Zeit in Anspruch nimmt.
Garrelt: Das stimmt. Das, ja. Und ich glaub, das war bei uns irgendwie praktisch, dass wir das halt schon hatten. Und am Ende fühlt sich das gut an, die diese Sicherheit zu haben. Und auch wenn es am Ende vielleicht eine Handvoll mal wirklich Probleme aufgezeigt hat seitdem, das läuft jetzt, glaub ich, 3 Jahre oder so, fühlt es sich immer gut, dann das zu haben und so zu wissen, okay, machen jetzt nicht irgendwo random kaputt visuell. Aber ne, die auch, wo Du Thema Animationen angesprochen hast, wir haben aber jetzt auch nicht alle Statements damit abgedeckt, ne. Also wie viel Prozent von unseren damit jetzt abgedeckt ist?
Jan: Aber das ist halt bei Testing auch immer so die Abwägung, ne? Also das ist ja immer so Risiko, Cost, Benefit, irgendwie, alles zusammen. Also ich sag immer, jemand, der mir zeigt, wie er 100 Prozent Coverage in seiner Code Base irgendwie hat, dem kann ich zeigen, wie er hunderte Arbeitsstunden verbrannt hat für wahrscheinlich nicht so widerlich. Also es gibt bestimmt, wenn Du jetzt, weiß nicht, in irgendwie Rocket Science oder irgendwie Medizintechnik oder so, dann hat das bestimmt irgendwie alles seinen seinen Hintergrund, ja? Aber ich glaub, für die Software, die die allermeisten von uns irgendwie bauen, wird das schon so in Ordnung sein.
Garrelt: Es gibt halt und die muss man identifizieren. Und da würd ich sagen, Du wohnst es immer, Tests zu machen. Die Frage ist halt, wie viele hat man davon?
Jan: Habt ihr mal überlegt, kleines Gedankenexperiment, hab ich früher mal gemacht, eure Liveproduktivanwendung mit zu testen?
Garrelt: Du meinst, dass Du son Test machst, der wirklich auf die URL geht von der eigentlichen Anwendung und da dann die gemacht? Ja. Nee. Hab ich noch nicht überlegt. Ist natürlich dieselbe Frage, wie machst Du das Set-up? Wie kriegst Du denn User und so?
Jan: Also ich hab das im Rahmen 1 E-Commerce-Projektes, da freu ich's, ich weiß nicht, was man da so erzählen kann, mal gemacht. Wo heißt dann, okay, der der Checkout- und Warenkorbprozess, der ist halt ultrakritisch, weil da geht halt den ganzen Tag Cashflow drüber so, ne. Also lass uns doch 'n automatisierten Test bauen,
???: Mhm.
Jan: Der halt alle, ich weiß es nicht mehr, halbe Stunde, Viertelstunde, x-mal am Tag halt einfach auf die Webseite geht, sich 'n paar Sachen in den Warenkorb legt, zum Checkout geht und dann halt im Prinzip alles macht, bis auf die Kreditkartendaten einzugeben. Ja. Weil das, also a Kreditkartendaten faken und so immer 'n bisschen Ja. Schwierig und b ist es auch rechtlich gar nicht so ohne, wenn Du als Firma quasi Einkäufe bei dir selbst tätigt, weil das Fake quasi Umsatz, der nicht, also schwierig, da muss man aufpassen, so. Also wenn ihr das machen wollt, nicht auf den Knopf drücken am Ende, aber ihr könnt vielleicht bis dahin kommen. Ja. Dann halt einfach zu sehen, so, ne, funktioniert der Flow halt irgendwie grade für uns auf der Webseite. Was für E-Commerce und so, ne, bestimmt noch mal 'n bisschen kritischer ist. Ja. Als jetzt in Anführungszeichen nur bei Gaming, nicht dass Gaming nicht wichtig ist, aber da ist halt, da gibt es nicht diesen einen neuralgischen Punkt für den für den Cashflow, sondern ist halt so Werbeausspielungen und so was viel interessanter. Mhm. Aber trotzdem irgendwie, ich fand die Idee supercharmant zu sagen, na ja, halt ab und zu irgendwie damit auch aufs Pod System zu gucken und zu schauen, ob alles geht, war irgendwie auch ganz cool.
Garrelt: Aber was Du, also ich glaube, bei uns wär's mein Gedanke, wir haben ja die User, die's testen und die
Jan: und die Garabon Quality Experte unter der Programmierer waren,
Garrelt: ne. Ja, aber jetzt erinnert's mich an
Jan: das Zitat, ich mein, irgendwo hab ich's meine in der in 'nem Talk in der Präsentation gesehen so, jeder Entwickler hat ein Testsystem und nur die Reichen können sich ein dediziertes Protzystem leisten. Und das, ja, ist eigentlich so.
Garrelt: Warte, war's das, sag ich dir, sag das noch mal.
Jan: Jeder Entwickler hat ein Testsystem. Ja. Und die Reichen können sich ein dediziertes Protzystem leisten, was im Prinzip eine Anspielung darauf sein soll so, auch wenn Du denkst, dass Du kein dediziertes Testsystem hast, hast Du halt 1, weil da, wo deine User rumturnen, ist im Prinzip auch 'n Testsystem.
Garrelt: Ach so.
Jan: Ja, so. Weil wenn Du kein anderes Testsystem hast, ist spätestens das dein Testsystem.
Garrelt: Ja, ja. Sehr okay.
Jan: Ja. Hannyway.
Garrelt: Ja. So. Es ist auch so.
Jan: Du hast Du hast die User, ja.
Garrelt: Genau. Und ich mein, wenn jetzt irgendwas in in, keine Ahnung, zum Beispiel in sonem eigentlichen Spiel, also in dem Chor, wie wir nennen, nicht laufen würde, dann würden das unsere Zahlen, glaub ich, viel früher sagen als irgend 'n Testuser, der das testet, oder?
Jan: Ja, wahrscheinlich. Also ich glaub, 2 Punkte. A hab haben wir natürlich eine viel größere Masse an Usern, sodass viel früher auffällt, Mhm. Wenn was kaputtgeht. Also Du kannst allein durch wahrscheinlich superviel feststellen, so. Wenn auf einmal die gespielten Spiele pro Stunde oder pro Tag in den Keller gehen, dann wirst Du's schon irgendwie merken. Ja. Und da ist 'n natürlich auch 'n ganz anderes emotionales Attachment irgendwie da. Ja. So, ne, wenn ich jetzt, weiß nicht, 4 Bilder, ein Wort, wisst man, irgendwas funktioniert nicht, dann reg ich mich auf, dann melde ich mich da, bla, weil ich will jetzt hier grade spielen so. Das hast Du natürlich im E-Commerce-Base irgendwie weniger. Ja. Da hast Du halt viel eher das Risiko, dass boah, das funktioniert jetzt hier grade nicht, ich kauf's woanders. Und dann ist natürlich Schön.
Garrelt: Und die Gründe können da ganz andere sein, warum vielleicht auch mal Leute 'n Checkout nicht machen, da hast Du viel mehr Wege dorthin und so.
Jan: Genau, da haben wir zum Beispiel auch so was gefunden. Egal, ich will da gar nicht so so viel drüber erzählen, aber man kann ja natürlich diese Tests, diese automatisierten Tests auch von verschiedenen Orten ausmachen. Also ich kann sagen, ich host das einmal meinen meinen Testrunner sozusagen einmal in Deutschland. Ja. Ich host den einmal in USA, ich host den einmal irgendwo in Asien. Und dann findest Du natürlich auch irgendwie in deinem CDN oder so was Probleme relativ schnell. Und da weil Du sagst, okay, für die deutschen User funktioniert das, für die in Amerika irgendwie nicht. Das ist dann auch ganz interessant.
Garrelt: Aber wo wir schon mal bei den Sachen sind, die ihr gemacht habt, wie ist denn, wenn Du jetzt über Playrate so gehört hast, wie das funktioniert, siehst Du da große Unterschiede zu dem, wie euer Set-up war? Ist irgendwas viel einfacher als früher?
???: Also es
Jan: ist natürlich grade, was das Set-up angeht, brutal viel einfacher. Ja. So, ja, mit mit Papperier und hast Du alles nicht gesehen, da ist ja so viel schon an irgendwie mit drin. Wir haben uns damals noch 'n eigenen Zwischenlayer geschrieben und da ist vielleicht dein Take irgendwie auch mal ganz interessant zu, weil wir so was wie, ja, was sind denn so Assets, die man halt relativ häufig macht? Also, ne, gern, wieder ausm E-Commerce-Base kommt, aber vielleicht gibt's ja auch das analog zu euch. Stell dir vor, Du bist jetzt irgendwie auf der Seite unterwegs und Du klickst dir deinen Warenkorb zusammen und dann willst Du halt 'n Asset machen, der halt sagt, und jetzt sollte die Summe deines Warenkorbes 50 Euro betragen.
Garrelt: Mhm.
Jan: Dann kannst Du natürlich sagen, jetzt klickst Du auf das Warenkorb Icon, Du guckst unten in das Label und bla. Mhm.
???: Und
Jan: da haben wir halt irgendwie 'n anderes Asset für gemacht, was dich halt, was halt so, wenn Du den Test liest, dass viel näher an menschlicher Sprache halt irgendwie ist. Ich bin immer 'n Freund davon, Quelltext maximal lesbar zu gestalten, Mhm. Ja. Und nicht in 3 Einzelschritte irgendwie Pubertät zu sagen, was er machen soll, sondern lieber dafür einen Helfer zu bauen, der sagt, okay und jetzt, ne, sollte halt dein Warenkorb Wert x y sein oder jetzt solltest Du folgendes Produkt sehen und so, ne, das halt einfach son bisschen kompakter noch irgendwie machen zu können.
Garrelt: Ach, er hatte dann so was wie eine Funktion, Warenkorb sollte jetzt Dinge sein und dann konntest Du das so lesen und der Genau.
Jan: Oder Produkt x y sollte im Warenkorb sein. Und dann macht er im Hintergrund natürlich genauso diese Sachen.
Garrelt: Cool, ja.
Jan: Aber es liest sich halt, wenn Du den Test anguckst, verstehst Du halt von jetzt auf gleich im Prinzip, was da passiert. Ja. Und das ist relativ wenig HTML und Browsersprecht sozusagen, das Ja. Ne. Das fand ich irgendwie immer noch noch ganz cool.
Garrelt: Find ich's absolut sinnvoll bei 'nem Test, der auch so visuell am Ende läuft, ne. Also wenn Du, ich find's auch immer gut, wenn Du den Test dann liest, ungefähr verstehen zu können, was da passiert, weil irgendwie Klick auf macht das so. Also es ist ja
Jan: Ja, und grade wenn Du, ne, Du hast vorhin so die die Selektoren und so was angesprochen. Grade wenn da jetzt klick und dann machst Du son CSS Selektor irgendwie hinten dran.
???: Ja.
Jan: Da hat ja keine Sauna Ahnung, was Du irgendwie meinst, wenn Du Punkt, Ja. Punkt, bla irgendwie so, ja. Und wenn Du einfach sagst, und jetzt klickst Du auf den Checkout Button Ja. Das halt irgendwie einfach.
Garrelt: Ja. So. Voll.
Jan: Und so was haben wir halt superviel gemacht.
Garrelt: Okay.
Jan: Was am Ende natürlich dann auch hilft, wenn diese Tests son bisschen instabil werden, weil sich was am Layout ändert.
Garrelt: Mhm. Dann musst Du
Jan: halt nicht 500 Tests anpassen, die alle deinen Checkout Button suchen, sondern Du hast halt eine Helperfunktion, Ja. Die quasi so der Rapper für deinen Checkout Button ist
???: Ja.
Jan: Und fertig.
Garrelt: Wie viele Tests hattet ihr so?
Jan: Ich weiß es nicht mehr, aber Dutzende. Also wirklich viel End zu End Zeug da auch schon gebaut. Mhm. Ja. Und das wär so mein mein 1 Tipp vielleicht noch irgendwie.
Garrelt: Lieft das stabil? Oder hattet ihr auch Probleme, dass In
Jan: dem Set-up lief das stabil, wenn ich mich an meine ganz frühen End zu End Testerfahrungen zurückerinner, dann waren tatsächlich so Sachen, Du hast es am Anfang so superlapidar gesagt, na ja, der wartet halt bis die Seite fertig geladen ist und dann guckt er, ob irgendwie dein Asset halt stimmt. Das war früher abgefahrene Rocket Science, so was hinzukriegen.
Garrelt: Das glaube ich.
Jan: Also ich hab tatsächlich Test Assets geschrieben, die so 'n Scheiß machen wie, guck, ob der Loadingspinner sich noch dreht, guck, ob dein Browser noch irgendwelche offene Network im Hintergrund hat. Und erst, wenn das alles fertig ist so, ja, dann führ halt irgendwie das Asset aus, was, wenn ich schon 30 Sekunden warte? Nein, dann brech halt lieber irgendwie ab. So, ja, das musste man alles früher von Hand machen.
???: Und
Jan: das war und vor allen Dingen auch was, wo's halt gefühlt so ganz wenig gescherte Best Practices gab. Also wir haben einfach für uns selber irgendwie rausfinden müssen, was ist halt sone gesunde Threshout, die man halt irgendwie warten muss auf sone Angular Anwendung oder so was, ja. Oder wie viele Network macht eigentlich son Framework im Hintergrund die ganze Zeit und Mhm. Bla bla bla so, ja. Und wenn ich das alles heute nicht mehr machen müsste oder offensichtlich nicht mehr machen muss, dann ist das, glaub ich, schon
Garrelt: Ja. Einfach. Das eine, also auch noch 'n Thema ist, dass es relativ, also PlayWorld ist relativ gut darin, so Flagy Tests zu finden. Weil wenn 'n Test fehlschlägt, dann lassen die den auch wahrscheinlich konfigurierbar, bei uns ist es zweimal laufen. Also wenn der fehlschlägt, machen sie ihn noch mal.
Jan: Heißt okay.
Garrelt: Wenn er dann einmal, also erst mal fehlstellen und dann funktioniert, dann merken sie ihn halt als. Und das kannst Du Aber was
Jan: heißt das für deinen? Heißt das erfolgreich oder nicht erfolgreich?
Garrelt: Gute Frage.
Jan: Ist das so erfolgreich mit Sternchen? Du solltest es dir bei Gelegenheit mal anschauen oder ist es so, nee, heißt eher so, ist durchgefallen?
Garrelt: Ja, also wenn ich raten müsste, kann man das auch konfigurieren. Bei uns geht's, glaub ich, durch, wenn er das zweite Mal's schafft. Weil er dann wahrscheinlich das erste Mal davon ausging, dass irgendwie Networkprobleme war oder so was. Ist aber bestimmt auch konfigurierbar. Und ich wette, dass Du auch konfigurieren kannst, wie oft der es halt probiert, rauszukriegen, wie ist es. Aber ja, ist halt, also ist wahrscheinlich grade auch bei 'n sehr viel größeres Thema als bei Juni Tests.
Jan: Also es gibt Fehler und Flagy Tests, ich hab mir grad die Config aufgemacht, leider steht der Default Wert nicht da. Ah, das hilft mir jetzt nicht. Ich will das wissen. Standardmäßig 3, ja, okay.
Garrelt: Nee, ich glaub, ansonsten, dann haben wir's vielleicht umgestellt.
Jan: Ja, vielleicht hat sich das auch einfach irgendwann mal geändert. Ja, aber so was ist halt schon cool, weil also am Ende Mhm. Ich find's immer schwierig, wenn halt so, also egal, ob das jetzt in der Test execution ist oder in dem Mindset, mit dem man die Tests schreibt, so ganz dogmatisch, hilft es dir halt auch nix so, ne. Ich hab mal 'n sehr guten Vortrag von jemandem gehört, der hat gesagt, 'n Test ist halt 'n Tool, was dir helfen soll und nicht 'n Tool, was dir im Weg rumsteht. Ja. So. Und das ist, glaub ich, sone gesunde Einstellung, da irgendwie dranzugehen.
Garrelt: Ja, es ist, glaub ich, manchmal 'n bisschen schwer, das abzuwägen, ne, wann er dir hilft und wann hätt ich eher stört.
Jan: Aber es scheint ja, als ob ihr irgendwie 'n gesunden Kompromiss gefunden habt.
Garrelt: Ich denk schon, ja. So, nachdem wir
Jan: jetzt schon fast eine Stunde hier dabei sind, was ist immer meine letzte Frage am Ende, Gareth?
Garrelt: Was hättest Du mich, was hätt ich gerne, dass Du mich gefragt hättest, worüber wir nicht gesprochen haben?
Jan: Sehr gut, muss die Frage gar nicht stellen, kannst die Antwort gleich selber mitgehen.
Garrelt: Also erst mal find ich, Du hast sehr gute Fragen gefunden. Ich bin tatsächlich ziemlich überrascht, wie lange wir über dieses Thema so gut sprechen könnten. Du machst das schon nicht ohne Grund.
Jan: Das das das klingt so, als wär's wieder so ultrapessimistisch in diese Folge gestaltet
Garrelt: von so.
Jan: Ah, ich glaub ja nicht, das ist, was wir dabei erst mal versuchen.
Garrelt: Also ich bin ich bin in diese Folge gekommen mit dem Gedanken, es ist jetzt nicht so, als hätt ich superviel Ahnung von Playrite. Wir haben das jetzt nicht, wir haben keine Dutzend Tests gemacht. Wir haben 5 und 'n Visualygaessen Test Setup. Also das wirkt alles sehr, sehr klein sozusagen, was wir damit gemacht haben. Und Aber
Jan: es reicht ja, den Leuten 'n Eindruck zu vermitteln, wie's funktioniert und vielleicht 'n paar Leute zu inspirieren, dass sie sich's auch mal anschauen. Und dann haben wir schon was geschafft.
Garrelt: Das stimmt. Aber ja, gefühlt hätt ich gesagt, ich hab in 10 Minuten alles gesagt, was ich zu diesem Thema weiß. Offensichtlich nicht, also
Jan: Waren sehr lange 10 Minuten.
Garrelt: Ich bin auch sehr gut darin, das zu ziehen vielleicht. Was was hätt ich's noch gern erzählt? Vielleicht nur, dass wir überlegen, es wieder abzulösen mit V-Tests. Weiß jetzt nicht, wie gut es ist, das am Ende des zu sagen, aber V-Tests hat auch Tests eingeführt. Die brauchen ja 'n viel kleineres Set-up als einen richtigen End to End Test. Und
Jan: Dann würde der aber auf die End to End Tests versuchen.
???: Genau,
Garrelt: das ist jetzt die Frage sozusagen, brauchen wir die wirklich oder wär es auch okay für uns, die rauszukicken und alles auf Tests zu haben, weil wir WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
Jan: den Tests zu hoch oder was was ist da das ausschlaggebende Argument? Oder Wir sind ja die beiden des Anstoßes?
Garrelt: Wir sind eigentlich immer son bisschen dabei zu gucken, welche Dependencies wir abbauen können, weil Dependency Updates immer bisschen nervig und aufwendig sind. Jetzt bei Playright nicht mehr als jede andere auch. Vielleicht 'n bisschen, weil sie eben auch das mit den und so mitbringen, aber eben auch so dieses, man braucht halt son Dock Setup. Und sie sind eben auch manchmal bei uns und da muss man immer mal reingucken, also die Überlegung ist auch, diese End to End Tests, wollen wir die so noch haben in diesem Kontext? Oder reichen uns die Visual Regation Tests? Und das ist grad son Überlegung, seitdem das eben verfügbar ist in b-Test, ob uns das reichen würde, auch darüber zu machen.
Jan: Aber Testing in b-Test würde ja auch wahrscheinlich so was mit Papiertier oder so was.
Garrelt: Lustigerweise nutzen die das, also aber nicht als nur diesen Browser, den sie nutzen. Also ist nicht wirklich Pabertät, die haben noch mal das noch mal abgewandelt und Du kannst
Jan: Worauf ich hinaus will, ist eigentlich nur, ihr werdet euch 'n Teil der Dependencies ja wieder reinholen, damit halt als indirekte Dependency.
Garrelt: Das stimmt.
Jan: Aber alles, was jetzt allein aus, ich sag mal so, Security Concellen oder so was wär, Ja. Hängt trotzdem wieder mit drin.
Garrelt: Aber darum muss man sich dann weniger kümmern. Also das, ich würde hoffen, dass V-Test, wenn sie 'n Update machen oder wenn 'n Update macht, sie sich selbst darum kümmern, dass das auch kompatibel ist. Das also, ja, das sind so die Überlegungen. Faire Frage. Ja, aber nicht, dass irgendwie schlecht wär. Wir sind nur immer sehr aktiv darin zu gucken, können wir die abbauen, Weil das immer son bisschen auch eine
Jan: Ist ja keine schlechte Grundhaltung.
Garrelt: Ja, genau. Das ist
???: mal ab
Jan: und zu zu hinterfragen, ja. Okay. Ja. Dann, was machen wir immer nach unserer letzten Frage?
Garrelt: Der heiße Stuhl. Nee, den. Er hat doch früher mal so diese Fragen gemacht, die so, wie hieß 'n das noch mal, diese kurzen Frage?
Jan: Die Schnellfragrund, aber das ist ja
???: nur im
Jan: City die Auspecial.
Garrelt: Ah, okay.
Jan: Und auch da machen wir das seit Neuestem auch nicht mehr.
Garrelt: Ja, ich weiß. Ich dachte nur, dass das früher bei den Deep Darts auch wär.
Jan: Hörerinnen, die erst vor Kurzem dazugestoßen sind, denken sich jetzt, ah, was, schnelle Fragen, hab ich noch nie gehört.
Garrelt: Und früher gab's, kennst Du Alberto, den den Youtuber? Nein. Der ist auch schon 'n bisschen älter, aber der hat dann immer am Ende seiner Videos den heißen Stuhl gemacht und da war genau das. So irgendwie so schnelle Fragen von irgendwie Subscribern, die er dann so schnell beantwortet hat. Nee, Pix of the day machen wir.
Jan: Was sind deine?
Garrelt: Mehrere, nee, ich hab einen.
Jan: Lass einen, dann hau mal raus.
Garrelt: Ich mach ich mach heute einen. Wir dachten eben, dass wir schon mal als Pick genutzt haben. Ich glaube aber, wir haben schon mal drüber gesprochen, deswegen dachten wir das. Stimmt, ich habe schon mal drüber gesprochen. Heute bring ich sie noch mal als Pick mit, weil ich es letztens noch mal sehr gefeit hab, dass ich nutze. Und zwar, und Du könntest es jetzt wahrscheinlich fünfmal besser erklären als ich, aber Du darfst gleich Lücken füllen. Talescale ist eine Software, sich eben ein VPN einzurichten. Das heißt, ein, wo man so Vorteile hat wie, ich hab einen Raspberry Pi zu Hause, auf den möchte ich aber auch von meiner Arbeit zugreifen. Und damit ich keine Ports irgendwie freischalte oder irgendwie 'n DNS einrichten muss, nutz ich, ein Netzwerk zu haben, wo dann der Raspberry Pi und mein MacBook, egal wo sie sind, zusammen drin sind. Das heißt, ich kann meinen Raspberry Pi über eine bestimmte IP erreichen. Und da hab ich son paar Sachen drin, mein NAS, mein Raspberry Pi, mein MacBook, mein Handy irgendwie. Und die meiste Zeit läuft das einfach nur und ich brauch's nicht unbedingt, aber in manchen Situationen ist es dann extrem schön, da so einfach drauf zugreifen zu können. Und Installation supereasy. Es gibt einen sehr großzügigen und netten und laut, das hast Du mir immer erzählt, laut dem Gründer davon wird das auch immer so bleiben. Und es fühlt sich einfach alles sehr sympathisch, gut gemacht und gut erklärt an. Macht Spaß, das zu nutzen. So, jetzt darfst Du Lücken fühlen.
???: Ich weiß
Jan: nicht, was war da denn die Lücke? Also ich ich benutz Talescale ja auch. Talescale nutzt, glaub ich, dieses WireGuard Protokoll unten drunter, das VPN aufzubauen. Warum ich das cool finde, ist, dass es halt nicht nur den klassischen remote VPN Use Case erfüllt von, ja, ich sitz jetzt hier in der Firma und ist aber so, als wär ich zu Hause in meinem privaten Netz oder andersrum. Sondern das ist halt echt sone komplette virtuelle Netzwerk Administration, ne, also Du kannst virtuelle DNS Namen vergeben, die halt irgend, also DNS Einträge, Hostnamen, die dann einfach so magicmäßig funktionieren, egal wo Du grade bist. Du kannst auch gutes Access Management betreiben, weil mir zum Beispiel können nicht alle Member von meinem Talescale Netz auch auf meinen NAS und Home Server zum Beispiel drauf oder nur auf bestimmte Services davon und so. Also man merkt halt schon, dass es echt featurstark ist, weil das halt eigentlich für son Enterprisey Umfeld ist und sie ist uns freundlicherweise alle erlauben irgendwie mitzunutzen. Ist aber auch 1 von diesen Service, wo ich sagen würde, also wenn die jetzt morgen sagen würden, das gibt grad Free Tier mehr und das kostet 5 Euro im Monat, würd ich auf jeden Fall einfach 5 Euro da hinschmeißen. Mhm. Weil also so viel von meinem Zeug da irgendwie schon drauf aufbaut. Das ist sehr cool, Geldscale.
Garrelt: Ja. Find ich auch. Und die Firma wirkt einfach sympathisch. Ja. Coole Leute. Ja.
Jan: Ich hab was mitgebracht von, ich weiß gar nicht, wie man das ausspricht, vielleicht hätte ich mich besser verbreiten sollten. Es gibt imich wird es geschrieben, imich dot app. Mhm. Oder Image. Ah, oh, scheiße, man muss ja einfach nur voll drüber nachdenken. Image. Also IMMICH und wenn man das auf Englisch aussprechen würde, Image Mit. Wie Bild, weil das ist eine Foto- und Videomanagement.
???: Ja, gell.
Jan: Das ist son bisschen dein persönlich gehostetes Google Fotos. So ähnlich wie unser Fotos, was wir ja nutzen, ja. Son ähnliches Featureset bringt es damit. Aber ich will gar nicht über Image reden, sondern die Image Developer, die das alles Open Source entwickeln, die haben was veröffentlicht oder pflegen das schon sehr lange, was sie nennen, also verfluchtes Wissen.
???: Mhm.
Jan: Und das ist sone Fortschreibung von Fehlern und Bugs, die sie gefunden haben, die sie gerne niemals gefunden hätten. Und jetzt sind sie, weil sie das wissen.
Garrelt: Okay. Und
Jan: das ist sone sone Ansammlung mit jeweils Blogposts und Error Reports und so was hinten dran und Bug Reports, wo sie das dann gefeilt haben und so was alles. Aber hier zum Beispiel ist ja was, was jeder kennt.
???: Mhm. Und
Jan: diese ganzen Artikel fangen immer an mit, also. In JavaScript ist. Also wenn Du das mit sehr kleinen Intervallen benutzt, ich nehm mal an, so was wie 1, 2, 3, 4, 5 Millisekunden so, ja, dann macht dein Browser halt je nach Browser was ganz anderes daraus. Vielleicht, weil sie verschiedene nicht spezifizierte Minimumwerte haben, die sie quasi abwarten zwischen oder so was, ja. Und so wissen einfach, was Du halt wirklich nur merkst, wenn Du mal wirklich in sonen Bug irgendwie ganz tief reingetreten bist und eingetaucht bist. Und da haben sie halt ganz viele Sachen, so, ja. Angefangen bei in Windows und in Yamel und und und was halt alles an diversen Stellen irgendwie Fehler verursachen kann. Und ich find's halt cool, dass sie das alles so so mitloggen und auch irgendwie sehr menschlich beschreiben, weil es ansonsten so Arten von Fehlern werden, die, wenn Du sie selber mal findest, niemals irgendwie die Lösung ergoogeln könntest so, ja. Und deshalb bin ich sehr dankbar dafür und das irgendwie, weiß nicht, sehr, sehr menschlich. Und Sie schreiben so drüber so, Wissen, von dem wir gehofft hätten, das nie zu haben und jetzt mit euch teilen. Weiß nicht.
Garrelt: Aber es find ja, es find ich sympathisch, weil das ist ja was, was uns wahrscheinlich auch schon 'n paarmal vorgekommen ist in unseren Entwickler, unserem Entwicklerleben, aber es, ja, es, man erzählt's dann halt auch irgendwie nicht so, ne.
Jan: Ja, und das einfach mal so zu sammeln und zu erzählen, ist vielleicht irgendwie eine coole Best Practice und deshalb dachte ich, kleiner Shoutout an Image. Ich bin mir ziemlich sicher, es heißt Image.
Garrelt: Image, ja, das ergibt irgendwie Sinn, aber es sieht cool aus. Aber Du hast es nicht installiert bei dir?
Jan: Nee, Du hast dich nicht, Wirtschaft, Sinology Fotos. Ja, aber
Garrelt: ich find das, das ist jetzt nicht, könnte besser sein.
Jan: Ja, aber es ist halt auch so komfortabel, als dass jede andere Lösung wahrscheinlich schon krass viel besser sein müsste, als dass die ganzen Migration da auf mich nehmen, weiß nicht. Anyway, eine Diskussion für eine andere Folge. Wir müssen mal irgendwann über Self Hosting oder so was
Garrelt: Ja, sehr
Jan: gerne. Sprechen können wir Voll gerne. Überlegen, was wir da machen. Dann, Gerald, 1000 Dank für die Zeit, für diese sehr erfolgreich unterhaltsame Folge wieder deines Erwartens.
Garrelt: Ich danke dir, dass Du das eingerichtet hast. Ehrlich gesagt, ich weiß nicht, ob Du dich dran erinnerst, aber Du hast ja auch gesagt, wenn wir eine Stunde spannend darüber reden, dann muss wir auch 'n Vortrag darüber machen.
Jan: Ich hab's ehrlicherweise schon wieder vergessen. Aber ich glaube, wir haben damit das nächste oder 1 der nächsten Meet ups auch gleich mit an Land gezogen.
Garrelt: Es gibt mir 'n Bestes. Wunderbar.
Jan: Cool, vielen Dank. Ansonsten haben wir auch bald eine Programmierkonten anstehen oder so.
Garrelt: Aber es darf, ich will ja Herr Aikram machen, so.
Jan: Mhm. Ich kann auch 2 Verträgen.
Garrelt: Ja. Die sind heute.
Jan: Dann 1000 Dank, Cari, 1000 Dank fürs Zuhören da draußen. Wenn ihr Fragen, Feedback, Anregungen habt, immer gerne an Podcast at Programmier Punkt bar oder einfach einen Kommentar auf den diversen Social Media Kanälen hinterlassen. Und einfach liken jetzt auch in den Shownotes. Ja. Einfach mal den Thumps up Button drücken, kommt direkt bei uns an. Ich hab's eben noch gesehen.
Garrelt: Es ist sehr schön geworden, Jan. Tausen Dank. Vielen Dank für dein Feedback. Jawoll. Danke euch.
Jan: Bis dann. Tschau, tschau.

Playwright mit Garrelt Mock

Shownotes

Picks of the Day

Tailscale

„Cursed Knowledge“ von Immich