Revision 652: Automatisiertes Testing mit Playwright

0:00Schepp Not My Machine ist jetzt nicht hier mein Kollege und meine Kollegin, die hier neben mir sitzt, wo ich mal rüberrollen kann, sondern das ist das Datacenter von GitHub, was irgendwo steht. Für dieses Problem gibt es halt Playwright Tracing. Das heißt, wenn jeder Testcase in Playwright durchläuft, nimmt Playwright alle Actions, alle Sachen, die in diesem Testcase, in dieser Browser Session irgendwie passiert sind, nimmt das Ganze auf.

0:21Schepp Und das ist so ein bisschen ähnlich, wie wenn wir jetzt eine Webseite entwickeln und wir haben halt die Chrome DevTools oder die DevTools of Choice oben, sodass wir halt Network Waterfall haben und hier das haben und so. Und man hat halt eine ähnliche UI.

0:51Vanessa Revision 652 Die Revision von Working Draft wird euch präsentiert von Midwald, den Veranstaltern des Head-in-the-Cloud-Summits. Liebe Hörerinnen und Hörer, ihr kennt Midwald ja mittlerweile als den Hoster von Nerds für Nerds. Aber Midwald macht noch mehr als nur Server zu bepütschern. So findet am 13. Juni 2015 auf dem Midwald-Summit Campus in Espelkamp, der Head in the Cloud Summit statt.

1:24Vanessa Auf dem geht's um Cloud und DevOps, es geht um Tech-Themen allgemein und ganz generell um kreative Vibes. Alle Infos findet ihr auf mitwald.de slash lp slash head strich in strich the strich cloud. Den Link zum Anklicken findet ihr auch in den Shownotes. Hinter diesem Link findet ihr die Ticketbuchung, den Newsletter, Videos des letzten Summits und den noch offenen Call for Papers.

1:48Vanessa Wenn ihr Nerds seid, den Kreativität Wenn ihr mit Tech, Cloud und DevOps am Herzen liegen, dann ist euch der Head in the Cloud Summit wie auf den Leib geschneidert. Alle Infos und Links findet ihr in den Shownotes zu dieser Revision. Wir danken Midwald für die Unterstützung von dieser Revision. Wir sind heute zu dritt. Da hätten wir aus dem Team den Peter. Moin, moin.

2:15Vanessa Ich bin der Shep und das bedeutet, dass wir wieder einen Gast da haben. Und zwar ist es diesmal der Stefan Judis. Hallo.

2:22Schepp Hallo, freue mich hier zu sein.

2:23Vanessa Ja, wir freuen uns auch. Du warst ja schon ganz oft bei uns, also ich würde sagen so dreimal bestimmt in den vergangenen Jahren. Wie das mal so ist, ist natürlich doch überraschend viel Zeit wieder vergangen und so weiter und so fort. Wir kennen das. Das ist eigentlich so die Parallele bei allen Gästen, die wiederkommen.

2:42Vanessa Ob schon, wie du dich ja damals schon vorgestellt hast, kennen dich vielleicht ein paar unserer HörerInnen noch nicht. Und deswegen erzähl doch mal, wer du bist.

2:51Schepp Ja, ich bin Stefan aus Berlin. Ich mache so Frontend-Kram, Web-Development, habe jetzt, weiß ich nicht, 10, 15 Jahre, habe ich so langsam auf dem Buckel, blogge viel, schreibe viel, teile viele Sachen im Internet, so kleine Fun-Facts über JavaScript, CSS, HTML, die Sachen. Und ich habe einen kleinen Newsletter, der nennt sich Webweekly für die Leute, die Bock auf Web-Development und Frontend-News haben.

3:22Vanessa Ja, der ist mega. Den machst du ja schon super lange und also da auch nochmal von mir super gut. Jede Ausgabe ist immer voll Gold-Nuggets. Also finde ich mega. Also du gräbst auch immer coole Sachen aus. Und ich glaube, du warst mal bei den WoWiSin ist vorne Podcast auch, richtig? Und da so mal erzählt, wie du das ganze Zeug ausgräbst, Und das ist echt cool gemacht, also wie du da quasi so dein Setup hast.

3:53Vanessa Und dann, genau, kriegst du das eben alles mit, was so da in Bewegung ist. Und genau, verstehst es auch und verarbeitest das so, dass wir alle eben das auch mitbekommen und verstehen. Sehr geil. Genau, deswegen würden wir empfehlen.

4:10Schepp Ja, ist halt gerade eine verrückte Zeit, ne? Gerade wenn die Browser oder die Specs ja gerade so viel irgendwie, es passiert halt unglaublich viel und ich versuche halt schon darauf, mich irgendwie zu fokussieren, erstmal versuche ich relativ wenig Framework-News irgendwie zu machen, weil ich möchte schon sagen, so Plattform-Standards, wenn man weiß, wie das Web funktioniert, dann kriegt man sich schon in irgendwas Schwieriges reingearbeitet, und ich versuche halt wirklich so fokussiert auf, was sind die Specs, wie funktioniert der Browser, was ist gut UX, so dieses, ah, so, und das ist so mein Anspruch und ja, freut mich, freut mich, dass ihr gefällt, Shep.

4:45Vanessa Ja, also stehe ich ja auch absolut drauf auf so Sachen.

4:49Schepp Du bist heute drin. Du hast deinen jährlichen Blogpost geschrieben. Geht heute Abend noch raus. Ja.

4:54Vanessa Das hat er. Und das so früh im Jahr. Ich weiß auch nicht, was los war. Nee, es war einfach Spotsierverhand. Es gab halt ein Thema und dann habe ich es hingekriegt. Genau.

5:06Schepp Für die Hörer und Hörerinnen, Shep wird die SR-Only-Klasse ersetzen mit einem neuen Weg, wie man Sachen für alle findbar und lesbar machen sollte. Text. Ja, wahrscheinlich. Guter Post.

5:20Vanessa Ja, danke schön. Nee, war auch ein gutes Thema einfach.

5:24Schepp Ja.

5:26Vanessa Genau, also vielleicht kann man da nochmal spoilern. Geht mal auf unsere Seite. Und ihr wolltet ja immer schon in unseren Community-Slack rein. Und dann geht einfach auf unsere Seite, dann macht ihr Command-F oder Steuerung-F und dann sucht ihr mal nach Slack und dann guckt mal, was da passiert. Und darüber geht das. Genau.

5:48Vanessa Ja, auch sonst. Also bist du ja eine totale Content-Maschine. Also du hast ja viele Jahre als DevRel gearbeitet für verschiedene Firmen, hast in dem Kontext auch viel Content produziert, eben nicht eigentlich gar nicht nur über die Produkte dieser Firmen, sondern so, du hast dich ja immer begriffen, so als allgemeiner DevRel und dann hast du halt dein Kopi-T-Shirt vielleicht angehabt, aber im Grunde ging es gar nicht um die Produkte.

6:16Vanessa Das war auch immer super. Und auch jetzt bist du ja hauptruflich nicht mehr in Death Royale, sondern machst das so quasi auch, aber eben nicht nur noch. Aber das, was du machst, da ist ja auch super viel Content, den du immer noch produzierst. Und unter anderem ist das ja eine Serie über Playwright. Und da haben wir gedacht, da könnten wir mit dir mal drüber sprechen.

6:41Schepp Gute Überleitung. Seit zwei, drei Jahren beschäftige ich mich auch mit Microsofts Playwright. Ja, das stimmt. In Bild und Text und Video, wie man auch immer Playwright lernen möchte, benutzen möchte, versuche ich irgendwie alles abzudecken.

6:58Vanessa Ja, cool. Und du hast es jetzt auch gerade gesagt, das ist ein Microsoft-Produkt. Also, genau, ich habe das so krass als Microsoft-Produkt nie wahrgenommen, weiß aber wohl, dass Microsoft so dahinter stand, zumindest offenbar nicht nur in der Anfangsphase, sondern weiterhin noch. Und für mich war das so ein Tool, was auf, also aus welchen Gründen auch immer, die ich mir nicht erklären konnte, auf Puppeteer folgte, was ja damals oder was es auch immer noch gibt, aber das ein Headless und scriptbarer Chromium-Browser oder Chrome-Browser war.

7:36Vanessa Und ich habe mir das zunächst mal so erklärt, dass Playwright eben das Puppeteer ist, nur ein cooler. Ein cooler deswegen, weil geht auch mit Firefox und geht auch mit Webkit und ich weiß nicht, wahrscheinlich damals auch mit Edge. Aber das weiß ich nicht mehr so ganz genau.

7:55Schepp Geht auch immer noch. Und was du aber sagst, glaube ich, stimmt irgendwie. Dass Playwright bis heute, glaube ich, irgendwie so ein bisschen unterm Radar fliegt. und ich hab da auch tatsächlich keine ... Ich weiß nicht genau, warum das so ist. Also, Playrate an sich ist halt eine Library oder ein Testrunner, mit dem du, wie du halt sagst, halt jeden Browser irgendwie kontrollieren kannst.

8:17Schepp Und ich mein, wir sind lange genug dabei. Für uns hat das angefangen mit Phantom.js, ne? Und dann irgendwann kam Puppeteer, was zum ersten Mal so was Echtes war vielleicht irgendwie. Playrate kam dann halt irgendwann.

8:31Vanessa Es gab ja noch, ich muss jetzt nur so ein bisschen Nerd-Snipe noch, aber wir haben ganz, früher hatten wir ja auch immer den Sebastian Golasch hier zu Gast und der hat doch Dalek.js gemacht, das war doch auch noch so ein Ding.

8:43Schepp Genau, es war halt so der Community-Space, jeder hat halt irgendwie versucht, diesen Browser-Automation-Use-Case irgendwie abzudecken und das kam dann halt aus mehreren Ecken, das kann jetzt halt so, Browser, Scraping oder Automatisierung oder Screenshotting, so beispielsweise wie Sachen von OG-Images, Social Previews, das funktioniert ja meistens auch irgendwie mit einem Browser, der irgendwo hingeht und dann Screenshot, ein PNG rausspuckt.

9:06Schepp Oder dann gab es halt, ich glaube, das von Sebastian, das war halt auch tatsächlich test-driven. Das ist halt schon so eher End-to-End-Testing-Suite-mäßig. Aber die Grundidee ist halt, as a browser, ob jetzt headless oder headfull, also so, dass man mitgucken kann, automatisiert halt mal ein bisschen.

9:25Schepp Und dann guckt mal, was passiert, je nach Use-Case. Und da spielt halt Playwright heutzutage auch rein.

9:31Vanessa Und würdest du sagen, dass Playwright im Grunde da der Platzhirsch ist und Puppeteer den Rang abgelaufen hat? Schon, oder?

9:40Schepp Also ich denke schon. Aber ich bin natürlich auch so ein bisschen in der Bubble. Also ich hab halt Kontakt mit den Microsoft-Leuten ein bisschen und beschäftige mich natürlich sehr viel und sehr viel Zeit, auch mit Playwright an sich. Was ich aber letztendlich sehe, und ich muss zugeben, dass ich jetzt nicht so genau beobachte, wie oft Puppeteer released wird, wie die Features da laufen.

9:58Schepp Aber da ist auf jeden Fall hinter Playwright Power. Da ist halt jetzt ein Team von drei, vier, fünf, sechs Leuten, die arbeiten halt sehr hart daran, dass irgendwie in der Azure Cloud irgendwie, das ist natürlich der Nutzen für Microsoft, dass man das alles irgendwie in Azure laufen lassen kann, ist nichtsdestotrotz, aber trotzdem Open Source, kannst du in GitHub Actions, kannst du lokal, also kannst du es trotzdem benutzen, wie du möchtest.

10:21Schepp Aber die Geschwindigkeit und einfach nur, man merkt, dass da Bewegung im Projekt ist. Und einfach nur der Fakt, dass Playrate ist halt jeder Browser, jedes Operating System, eine API mit so ein paar Ideen, wie man halt Automatisierung leichter machen kann. und da ist einfach unglaublich viel Bewegung in dem Projekt.

10:40Schepp Und man sieht halt, es hängt so ein bisschen davon ab, von welchem Angle man kommt. Wenn man beispielsweise von diesem Browser-Scraping-Automation-Angle kommt, dann ist so ein bisschen Playwright oder Puppeteer sind da so die beiden Competitors. Wenn man aber von dieser Testing-Seite kommt, dann ist er Playwright oder Cypress sind da so die beiden Competitors.

11:01Schepp Je nachdem, was man halt machen möchte mit der Browser-Automalisierung. Und wenn man beispielsweise diesen Testing-Angle betrachtet, dann ist definitiv Playwright, nimmt mehr und mehr Platz ab von Cypress, einfach nur, weil Playwright ist Chromium-only und die User-Experience mit Playwright, da ist eigentlich einfach unglaublich viel Bewegung drin und es macht halt Spaß, Browser zu automatisieren.

11:24Schepp Also ich bin immer überrascht, wie schnell man sich irgendwas zusammentickern kann und dann guckst du halt zu, was passiert und es ist einfach ein cooles Projekt, coole Software.

11:34Vanessa Und automatisieren, da hatte ich ganz kurz den Gedanken, du kannst ja, glaube ich, in den Chrome-Dev-Tools auch so quasi so Sachen durchklicken und das irgendwie aufzeichnen. War das dann was, was du nach Puppety exportieren konntest? Oder geht das auch zu Playwright? Aber das nur so als kleiner Side-Track.

11:52Schepp Ich glaube, das geht ... Gefährliches Halbwissen, Achtung. Also, ich glaube, es gibt eine Browser-Extension, die Chrome-Dev-Tools irgendwie auch befeuert, sodass Playwright-Skripte da auch rausfallen könnten. Letztendlich spielt das absolut gar keine Rolle, weil Playwright hat ein Befehl Build-In, das nennt sich CodeGen oder CodeGeneration.

12:14Schepp Feuerst du ab auf der Kommandozeile, klickst ein bisschen in Chromium rum und kriegst das Playwright-Skript, das du haben möchtest, eigentlich Copy & Pasteable fertig. Du kannst auch vom VS Code direkt aufnehmen. Also es ist wirklich Klick vor, kriegen manchmal 50%, manchmal 80% fertiges Playwright-Skript, weil CodeGen ist normal nicht perfekt.

12:33Schepp Je nach Actions, Locators, da gibt es viele, viele Details, die können falsch sein oder schief gehen. Das ist mit Puppety auch ähnlich. Aber der Head Start und Getting Started ist ein Command und dann hast du irgendwas, was genau das macht, was du vorher rumgeklickert hast.

12:50Vanessa Okay. Und wenn wir jetzt noch mal kurz so einen Schritt zurückgehen, du hast ja gerade schon gesagt, also Playwright ist einmal Browser-Automation, da gibt es ja so verschiedene Motivationen, warum man das machen wollen würde. Du hast ja gesagt zum Beispiel, man könnte Screenshots machen, damit gescriptet in verschiedenen Auflösungen oder was weiß ich.

13:17Vanessa Man kann möglicherweise Dinge oder APIs ersetzen durch Browser-Automation, wenn man denn eine Webseite hat, in die man sich vielleicht einloggen kann und Dateien uploaden oder downloaden kann. So kann man das dann auch automatisieren, wenn es halt keine API gibt. Und das andere, was du gerade auch gesagt hast, war, dass man Playwright als Testsuit nutzt.

13:42Vanessa Analog zu, wie das eben bei Cypress der Fun ist. Und beide sind ja so ein bisschen spezialisiert auf UI-Testing. Das wäre auch das Parade-Beispiel. Da macht es ja auch Sinn, dass man eben eine ganze Browser-Engine hat, um diese UIs eben auch auf den Headless-Schirm zu bringen und sie dann da eben sozusagen abzufragen und abzutesten.

14:05Vanessa Und wahrscheinlich wäre so, genau, für Unit-Tests und so, da gibt es eben andere Frameworks für ebenso wahrscheinlich für REST-APIs durchtesten. Das sind wieder komplett andere Use-Cases. Dafür wäre Playwright einfach Overkill.

14:20Schepp Ja, also ich denke ...

14:21Vanessa Es kommt ein bisschen drauf an, was du genau testest, ne? Also ich hab Playwright bei mir an einer Stelle am Werk und da geht's halt dann auch um so Workarounds irgendwie. Der Browser macht es so, der Browser macht es so. Und da willst du natürlich Tests haben, die am Ende verifizieren, dass deine ganzen Workarounds auf der ganzen Palette von Browsern halt greifen.

14:38Vanessa Dass du halt hier mal für Safari links was umfährst und da mal für Chrome rechts was umfährst. Aber dass am Ende alle so das gleiche Ergebnis haben. Das ist dann auch nur ein Unit-Test. Und dann sieht halt so ein Browser aus wie Overkill. aber es kommt halt schon tatsächlich darauf an, Was genau willst du feststellen?

14:53Schepp Denke ich auch. Peter, du bist natürlich bestimmt wieder Cutting Edge unterwegs mit bestimmten Spezifikationen, die in Safari nicht funktionieren. Ich würde schon sagen, dass die meisten Leute benutzen tatsächlich Playred für das UI-End-to-End-Szenario. Einfach nur, um sicherzustellen, große Applikationen.

15:13Schepp Funktioniert Staging, bevor wir zu Pod deployen. Je nachdem, wie lange das dauert. Theoretisch, es gibt auch eine experimentelle Funktionalität, Component-Tests für dein Framework of Choice, kannst du theoretisch auch durch den Browser ziehen, wenn du möchtest, das halte ich für ein bisschen. Fragwürdig, ob ich das dann nicht irgendwie durchmocken könnte, ob das dann durch den richtigen Browser läuft, es gibt ja JSTOM oder so, die sind einfach viel schneller, weil du brauchst halt nicht zwangsläufig immer einen richtigen Browser, aber für den Fall halt, dass man seine Pre-Prods, seine Staging Environments gucken will, ob der Checkout funktioniert, ich meine, wir alle kennen die Production Bugs und die Regressions,

15:50Schepp Und dann kommt man halt ganz schnell in diese Diskussion, okay, wie viel End-to-End-Testing oder UI-Testing möchtest du haben? Ich bin jetzt ein großer Freund davon. Ich setze mich auch gerne hin und hole mir einen Kaffee und warte 30 Minuten und habe halt eine grüne Lampe für 150 End-to-End-Tests. Finde ich mega gut. Ich weiß, dass da nicht jeder ein Freund von ist, aber ich bin halt auch eher so eine nervöse Person, die halt immer Angst davor hat, jetzt irgendwie was im Brot kaputt gemacht zu haben und das ist halt so der Primary Use Case und wenn man Playwright als Projekt an sich irgendwie beobachtet und mal schaut, das ist auch definitiv, wo Microsoft das Projekt halt hinbewegt.

16:23Schepp Also es gibt zwei separate Projekte. Es gibt Playwright als Library. Das ist dann dieser Automation Case, wo man einfach nur, ich steuere jetzt Browser ABC fern oder dann hat man halt Add Playwright Test als separates Package und das ist dann halt ein full-fledged Testrunner mit all den Sachen, die man ja von allen Testrunnern irgendwie kennt.

16:43Schepp Before each, after each, test cases describe and all these kind of things. Und das ist definitiv der Fokus vom Projekt. Und das Ganze ist dann, ziehst du halt rein, kannst ein bisschen TypeScript schreiben und dann siehst du die Browser-Party going und kannst halt ein bisschen ruhiger schlafen. Und das ist das, was mich dann halt da schon unglaublich abholt, weil ja, wie gesagt, ich bin so ein nervöser Nerd, der deployt und dann fünfmal händisch checken muss, ob jetzt wirklich alles noch funktioniert. So bin ich.

17:12Vanessa Nee, das macht ja auch Sinn, also dass man zumindest so die wichtigsten Pfade, so die businesskritischen Pfade oder eben, wenn man jetzt kein Business hat, aber so die wichtigsten Pfade auf der eigenen Seite da in Code gießt und der die abgeht. Also die Nicht-Happy-Paths, die würde man vielleicht dann nicht alle erfassen, aber genau, macht total Sinn.

17:35Schepp Ja, ich meine, es ist halt die Frage, wie schlimm ist, wenn es kaputt ist, je nach Projektzustand und wie viele Leute involviert sind, aber vom E-Commerce-Business, also ich bin gerade zuständig für den E-Commerce, da ist jeder Checkout-Flow, jede Payment-Method und irgendwie alle Fälle, die im Checkout irgendwie schiefen, auch Validierung und das ist alles End-to-End gecovert, weil das kostet Geld, da kriege ich einen ätzenden Anruf am Samstag.

17:57Schepp Ja, und den will man nicht, ne? Genau, ob jetzt der Product Zoom irgendwo nicht funktioniert oder hier irgendwas fehlt, ja, ist jetzt meine Entscheidung, ob ich das jetzt irgendwie end-to-end covern möchte und dann einen Test beschreibe. Aber so Smoke-Tests oder diese Kernfunktionalitäten, denke ich, das Schöne ist ja auch, wenn man selbst irgendwie Entwickler oder Entwicklerin ist und man kennt sich so ein bisschen aus mit der End-to-End-Testing-Materie, das geht relativ schnell, dass man halt ein Feature schreibt und das dann einen Test zuschreibt.

18:23Schepp Und das keeps giving, wirklich. Das ist so ein schöner Flow. Wenn man jetzt beispielsweise Teams hat, wo halt QA und DEV halt zwei unterschiedliche Teams sind, dann wird das ein bisschen behäbig und ein bisschen schwierig irgendwie von Kommunikation. Was testen wir? Was läuft wann? Aber wenn ich als Entwickler dahergehe und ich baue ein neues Feature ein und ich schreibe ein End-to-End-Test, jeder ist happy. Also ich bin großer Advocate hier für mehr Tests.

18:46Vanessa Ja, ich finde, was da auch gut funktioniert, ist eben einfach so, wenn einmal was schiefgegangen ist, dann macht man den Test und dann hat man zumindest dieses Problem, dieses spezifische Problem nicht nochmal, dann hat man irgendein anderes und dann muss man dafür dann wieder einen Test schreiben. Ja.

19:05Schepp Ich meine, es ist halt immer schwierig, so mit der Balance, für das besagte E-Commerce-Projekt laufen meine End-to-End-Tests. Jetzt, ich arbeite an dem Projekt irgendwie ein Jahr, da dauern die End-to-End-Tests, jetzt weiß ich nicht, 15 bis 20 Minuten. So, das ist schon ein Weilchen, denke ich, aber ist trotzdem worth it.

19:20Schepp Aber das muss jeder für sich selbst wahrscheinlich entscheiden.

19:24Vanessa Aber kann man sowas nicht irgendwie auch super parallelisieren?

19:28Schepp Ja, ich habe parallelisiert, sechs laufen in parallel. Ich habe aber kleine Nerdfakten. Ich habe ein Staging-Environment, wo der PayPal-Checkout-Flow manchmal geschlagene sechs Minuten dauert.

19:43Vanessa Oha.

19:44Schepp Ja, wo mein Frontend halt sechs Minuten lang PayPal-Staging pingt und fragt, ob die Transaktion durchgegangen ist. Ich glaube, da kann ich nicht mehr rausholen, weil ich brauche nur dreimal diesen Fall haben und dann ist es schon schwierig.

20:02Vanessa Ja, okay. Aber generell gibt es wahrscheinlich da auch einige Tricks, irgendwie wie auf Multikern-Systemen irgendwie mehrere Playwrights abfahren oder wahrscheinlich irgendwie Sessions wiederverwenden, wenn man denn nicht explizit irgendwie from scratch immer das starten möchte, weil man, I don't know, sich immer den Login noch mal einmal durchtesten will oder so.

20:27Vanessa Da kann man wahrscheinlich auch einiges optimieren im Laufe der Zeit.

20:32Schepp Ja, für nicht so spannende Use Cases, wo das Staging Environment halt so langsam ist. Parallelisierung, wenn du Playwright ausführst, bei Default guckt die CLI, wie viele Kerne CPUs verfügbar sind und benutzt alle freien CPUs. Das heißt, normalerweise läuft sowieso alles in parallel. Für den Fall, den du beschrieben hast, Shep, Authentication, du willst nicht zwangsläufig jede Session irgendwie einloggen, ist aber natürlich the usual it depends.

21:00Schepp Wenn viele parallele Tests auf einem Account rumraffeln, dann passiert das auch relativ schnell, dass sie sich vielleicht in die Haare kommen. Aber das ist tatsächlich auch möglich, dass man halt einen Setup-Step drin hat, die ganzen Cookies, Local Storage, was auch immer ist, irgendwie to-dist schreibt und dann alle Tests abfahren.

21:17Schepp Also man kann da schon viel rausholen, aber natürlich, wie Peter gesagt hat, das Totschlagargument ist halt parallelisieren, parallelisieren, parallelisieren. Aber ab einem bestimmten Punkt.

21:27Vanessa Ja. Okay.

21:29Schepp Oder weniger Tests schreiben. Je nachdem, weiß ich nicht.

21:33Vanessa Du könntest ja auch den externen System, die ja dann die eigentlichen Auslöser für all deine Qualen sind, auf den Keks gehen.

21:39Schepp Ja, fair point.

21:42Vanessa Naja, da stößt du halt ans Limit. Du kannst ja parallelisieren, wie du willst, aber sobald du halt diesen einen Sechs-Minuten-Klopper da drin hast, weil sie bei PayPal ihren Kram nicht im Griff haben, dann kannst du halt auch nichts mehr machen irgendwann.

21:52Schepp Ja, also ich hab auch mit einem anderen Unternehmen gearbeitet, die auch ganz viel Playwright-Monitoring machen. Und da ist auch wenn es halt um Test-Execution-Time oder Flaky-Nice-Time und egal, je nachdem, wie groß das Projekt ist, nicht stabile oder langsame Staging-Environments sind so häufig und ich bin halt auch ein ganz klassischer Fall, wo Staging halt das Environment ist, was irgendwie zusammengeknüppelt ist, was ein bisschen länger dauert und dann, let's go, YOLO.

22:24Vanessa Genau, du hast eben gesagt, dieses Code-Gen ist ein cooles Werkzeug, um so erstmal so ein bisschen eine Ausgangsbasis sich zu schaffen, dass man einfach nicht so viel Fleißarbeit erstmal, Grundlagenfleißarbeit machen muss und stattdessen schreibt der einem im Grunde den Code Pi mal Daumen, wie man ihn haben möchte.

22:51Vanessa Das hat gesagt, klar, es ist halt nicht perfekt, das würde ich wahrscheinlich beziehen, äh, auf, du hast die Locators genannt, also so quasi, welchen Selektor entscheidet der sich jetzt, ich wege gerade aus, woher ich das auch kenne, dass man dann, ach ja, weiß ich nicht, wenn du jetzt im Browser bist und dann einfach da im Style Panel beim Element inspekten sagst du, ich will einen neuen Style anlegen mit dem Plus, dann sagt der so, ja, ich denke mir jetzt einen Selektor aus und dann nimmt der zum Beispiel die ID und hängt noch Punkt Klasse dran und dann denkt man so, ja, nee, das hätte jetzt nicht sein müssen.

23:29Vanessa Aber es nimmt halt quasi das, was er da vor die Flinte kriegt. Genau, und das würde man selber, hätte man das jetzt so nicht ausgewählt und hat möglicherweise auch Nachteile. Das heißt, solche Dinge sind dann diejenigen, die man nach dem Code generieren, dann nochmal gerade ziehen muss, nehme ich an, oder?

23:48Schepp Ja, genau. Das ist ja so der Punkt. Also da wird es schon eine bestimmte Logik geben. Also das funktioniert so, dass du halt Code-Gen abfeuerst. Und bei Default wird dann Playwright halt aufnehmen, was du tust. Das sind dann halt die sogenannten Playwright-Actions. Das ist dann halt vom Klick zum Hover, was auch immer du da rum vorwerkst in der Webseite.

24:06Schepp Das wird dann halt recorded. Und wenn du dann halt Lust hast, tatsächlich auch noch Assertions hinzuzufügen, kannst du halt, Playwright-Code-Gen kommt mit so einer Toolbar, die im Browser verfügbar ist. Und dann kannst du halt auch noch definieren, okay, ich möchte mir jetzt, dass diese Headline halt beispielsweise diesen Text hat oder ich möchte, dass dieser Button jetzt hier visible ist.

24:24Schepp Und dann kann man sich das halt so ein bisschen zusammenklickern und das ist letztendlich aber jetzt hier kein AI, kein KI, da ist halt eine Logik drin, die passt halt der HTML und die versucht halt die Recommended Locators irgendwie da rauszuspucken. Das heißt, überwiegend ist dann halt der Flow, nimmst du erstmal auf, guckst und dann musst du dich erstmal hinsetzen, vielleicht willst du hier noch eine Variable irgendwie rausziehen und hier nochmal was bis hin, weil es geht ja auch manchmal vielleicht um dry, don't repeat yourself, vielleicht möchte man auch ein paar Sachen nochmal refactoren, nachdem das aufgenommen wurde, aber der Fakt allein ist, dass, wenn ich mich jetzt hinsetzen möchte und ich möchte mich jetzt einloggen und

25:01Schepp das automatisieren, um jetzt irgendwas zu scrapen oder sowas, kostet mich keine zwei Minuten.

25:05Vanessa Ja, das ist natürlich cool.

25:07Schepp Das ist halt mega nice.

25:09Vanessa Ja, gerade für so Dinge, die man eben möglicherweise, die nicht lange existieren müssen, die erstmal so hell verleihen sind, die muss man dann vielleicht tatsächlich nicht aufräumen. Also ich glaube, wo du aufräumen musst, ist ja auch dann einfach, weil du schon die Erwartung hast, hey, in meinem Projekt könnte die Reihenfolge der Elemente irgendwie anders sein, deswegen bitte mal schon mal nicht Endschild benutzen, weil das geht dann irgendwie als erstes direkt kaputt und so, genau.

25:37Schepp Ja, aber du sprichst ja schon einen schönen Faktor an, weil vor einem Jahr oder so, vor anderthalb Jahren, gab es halt einen riesen, nicht einen riesen, aber schon einen deutlichen Change in, wie Playrate funktioniert und wie man halt Elemente irgendwie auf einer Webseite kontrolliert. Und vorher, ich habe das genaue Datum jetzt nicht, also sagen wir mal vor anderthalb, zwei Jahren, war es halt schon so, wie du das beschreibst, man benutzt halt CSS-Locators oder Selectors, um irgendwelche Elemente irgendwie zu lokalisieren.

26:04Schepp Easy peasy. Das könnte jetzt eine Test-ID sein, aber das könnte halt auch Hash, also klassisch-ID oder eine Klasse sein oder was auch immer. Und man kommt halt mit dem Developer-Mindset her und sagt, okay, jetzt habe ich hier Class CTA-Enth-Child-2 oder sowas. Überraschung, Überraschung, das wird wahrscheinlich ein bisschen kaputt gehen, wenn der Entwickler, die Entwicklerin jetzt nicht zwangsläufig die Person ist, die die Test maintaint und dann rollt irgendwie alles auseinander.

26:27Schepp Und vor anderthalb Jahren gab es dann halt schon einen Change, in wie denn die perfekten oder die besten Playwright-Locators dann aussehen sollten. Und die Änderung war halt dahingehend, dass der empfohlene Weg, jetzt halt Playwright zu schreiben, ist definitiv User oder Accessibility First. Das heißt, der Approach, den du halt immer, oder den Ansatz, den du immer nehmen solltest, ist halt, es spielt keine Rolle, welche Klasse, welche IDs, wo ein Element aufgehangen ist.

26:56Schepp Wenn da ein Button ist, da steht Kaufen drauf, dann möchtest du halt Page Get By Roll Button mit dem Text kaufen machen. Das heißt, es wird hart bevorzugt, dass man halt die Locators so irgendwie auswählt, dass es halt darum geht, was sieht denn der User? Oder was ist hier die User Experience? Und das solltest du testen.

27:17Schepp Und das sollte auch immer der Ursprung des ganzen Skriptes sein. Du definierst halt UI wie... Deine User da draußen das irgendwie wahrnehmen und dann definierst du den nächsten Zustand. Ganz, ganz oft sieht man halt Leute, die zwischendurch noch hier auf einen Network-Request warten oder hier noch darauf pollen, dass irgendeine Klasse kommt oder irgendwie sowas.

27:39Schepp Das spielt aber meistens, meiner Erfahrung nach, absolut gar keine Rolle. Weil Playred hat halt ganz viele Auto-Wading-Mechanismen und Wege, Flakiness und all diese Use-Cases abzudecken, ohne dass man sich halt mit Implementierungsdetails auseinandersetzen muss. Und das ist halt das Schöne daran. Und wenn man das jetzt natürlich mit dem Recorder irgendwie verheiratet, deswegen geht das schon irgendwie, wenn man einen Button klickt, dann wird Playwright höchstwahrscheinlich rausspucken, dass es tatsächlich ein Button ist und da steht Kaufen drauf.

28:11Schepp Von daher ist die Logik da zwangsläufig gar nicht mal so schwer. Was schön ist an diesem Approach, wenn man, ich weiß nicht, wie das über Ton funktioniert, Aber die Method ist tatsächlich Get by Roll und dann geht man nach der Accessibility Roll, also wirklich semantisch HTML mit einem bestimmten Text.

28:28Schepp Was das Schöne an dieser Sache ist, dass wenn ich jetzt anfange, meine Playred-Tests zu schreiben und ich möchte jetzt schon irgendwie glauben oder ich versuche halt schon semantisch korrektes HTML zu schreiben, manchmal ist das jetzt aber halt nicht so einfach, je nach Situation, vielleicht vercheckt man auch irgendwann was.

28:42Schepp Und das Schöne ist halt, wenn man anfängt mit Playred oder End-to-End-Testing durchzustarten, was halt Accessibility-First ist oder UX-First. Treffe ich dann halt, ich arbeite halt an einem Feature und ich treffe dann so die Barriere und denke so, hm, ich kriege das jetzt hier irgendwie nicht ordentlich zurechtgefummelt und um dann ordentlich einen schönen Locator zu schreiben und ganz oft ist die Ursache dann halt, dass ich dann dahin gehe und sage, ja, irgendwas stimmt hier aber auch nicht, so, ich habe vielleicht das falsche HTML-Element benutzt oder, weiß ich nicht, wenn ich ein Formular irgendwie auswähle, das hat dann keinen Accessible Name oder so eine Kleinigkeiten.

29:18Schepp Die fallen einem halt dann alle unterwegs auf, weil Playwright das halt enforced, dass man Accessibility und UX-first irgendwie geht. Und das ist halt so eine schöne kleine Sache. Und ich habe jetzt über das letzte Jahr, ein, zwei Jahre, irgendwie schon gesehen, dass wenn ich halt, ich schreibe ein Feature, halt HTML, CSS und JavaScript, dann fange ich an, das automatisch zu testen.

29:36Schepp Und weiß ich nicht, in 20, 30 Prozent denke ich so, Ja, nee, machen wir nochmal einen Schritt zurück. Das ist jetzt noch nicht so gut geworden. Das ist halt ein schöner Seiteneffekt. Kann ich empfehlen.

29:47Vanessa Ja, das ist ja im Grunde, also ich meine, es ist ja, man hangelt sich ja da auch durch eine Seitenstruktur, ähnlich wie das assistive Technologien ja auch machen und das liegt ja auf der Hand irgendwie. Das ist total sinnig und es ist einfach eine gute Idee, das so zu machen. Und eben auch diese Wechselwirkung zurück in die Entwicklung.

30:10Vanessa Also wenn ich was irgendwie nicht ausquält bekomme, dann muss ich vielleicht irgendwie doch nochmal oder muss jemand an den Code nochmal ran. Was ja so ein bisschen auch diese Philosophie ist von, dass man eben keine extra Dame mit dem Marco Brettschneider in der ARIA-Folge gesprochen. Es gibt ja auch eben diesen Ansatz, dass man hingeht und man hat dann nicht so eine Hidden Class oder so, mit der man irgendwie Sachen versteckt, sondern man sagt so, hey, nee, ich benutze einfach ARIA-Attribute wie ARIA-Hidden und daran koppel ich dann auch meine Styles.

30:48Vanessa Und wenn ich irgendwas verschwinden lassen will, dann setze ich nicht eine entsprechende CSS-Klasse drauf, weil dann ist es für die assistiven Technologien ja im Grunde immer noch da, nur für, oder wenn ich Pech habe, noch da. Und wenn ich ARIA-Hidden benutze, dann weiß ich eben, okay, es ist eben nicht nur für die Sehenden weg, sondern es ist auch für die im Accessibility-Tree weg.

31:13Schepp Ja, und das ist halt so den Fall, den du halt beschreibst, der ist halt mit diesem Ansatz, wenn man, egal ob jetzt Unit oder Infantest, wenn man halt mit diesem Ali-First oder UX-UI-First geht, das ist beispielsweise so ein Fall, der würde dir halt auffallen, wenn du jetzt einen Icon-Button hast, ob der jetzt hidden ist oder nicht, oder ob der ein ARIA-Label hat oder nicht, das ist halt so ein Fall, der würde dir halt auffallen, wenn du halt in diesem Szenario jetzt irgendwie keine Chance hast, diesen Icon-Button irgendwie nicht auszuwählen, entweder weil er halt ARIA-Hidden ist und du siehst ihn, gibt ja vier, fünf Fälle so in diesem Szenario, ist der Button jetzt sichtbar, aber nicht für Assistive Technology oder hat er jetzt ein RLabel oder ein Span

31:49Schepp oder sowas und das sind all diese, Fälle, die halt auftauchen, wenn du dann halt merkst hm, ja ich hab hier kein Label für diesen Button, weil halt irgendwie der Text drinnen fehlt oder weil das Label fehlt und das sind halt so schöne kleinen Momente, wo ich sage, ja schön hab ich einen Test geschrieben, der Test hat mir aufgezeigt dass meine HTML halt grad nicht so cool ist und da gibt mir halt das Herz oft.

32:08Vanessa Auf oft Ja, das war für immer cool. Also ein total sinnvoller und irgendwie auf der Hand liegender Wechsel. Ich habe wohl gehört von diesen Alley-First oder Alley-Based Locators, aber ich wusste gar nicht, dass das quasi das neue Hauptparadigma sozusagen ist.

32:34Schepp Nee, es ist schon, ich glaub, es kommt alles aus der Testing-Library. Das ist eine Unit-Test, Component-Testing-Library aus dem React-Umfeld. Ich bin mir ziemlich sicher, dass die damit angefangen haben. Also, es kommt nicht direkt aus dem Playwright-Team. Die haben das, glaube ich, eins zu eins kopiert. Und es geht dann schon, favorisiert ist halt Get by Roll. Aber dann gibt es halt auch so eine Sachen.

32:56Schepp Get by Roll ist halt, wenn du interaktive Elemente hast, weil die haben ja meistens eine Accessible Roll, like Button, Heading oder irgendwie sowas. Aber manchmal ist es halt tatsächlich auch wirklich nur, dass du halt erwartest, dass bestimmter Text auf der Seite vorhanden ist. Also es geht schon von Semantik.

33:13Schepp Wenn du was hast, cool. Aber es gibt natürlich auch Methoden irgendwie, die dann sagen, hey, get by text to be visible. So, get by text, Shep sollte irgendwo auf der Seite sein. Ist immer noch besser, als irgendwie daran zu gehen, okay, ich erwarte jetzt ein Element mit Podcaster, Klasse, wo Shep drinsteht.

33:29Schepp So, der ganze Ansatz ist halt immer irgendwie, okay, wir gehen, was der User möchte, was der User sieht und von da an bewegen wir uns in unserer Browser-Automatisierung. Und man sollte halt wirklich so viel wie möglich vermeiden, halt Implementierungsdetails irgendwie anzuschauen. Weil das ist halt auch das Resultat, wenn man diesen Ansatz halt geht, verhindert man halt auch Flakiness, was halt ein Riesenthema ist und das Allerschlimmste überhaupt, wenn man halt eine Test-Suite oder Automatisierungsskripte hat, die halt nur 70% funktionieren oder nur 90% funktionieren.

34:05Schepp Das ist dann halt, wo Development-Teams irgendwie das Vertrauen verlieren, wo die Leute halt genervt sind, machen wir hier ein paar Retries. Das sind halt oft irgendwie so Situationen, wo die Tests halt nicht zwangsläufig User-First gebaut sind, in meiner Erfahrung, oder wo halt Applikationen tatsächlich nicht richtig testbar sind, aus verschiedenen Gründen.

34:26Schepp Tests in jedem Falle zeigen aber irgendwelche Probleme auf und das ist halt eine schöne Sache. Und Flakiness ist oft ein Resultat von diesen Problemen, die tatsächlich auf dem Applikationslayer oder in der Seite selbst irgendwie funktionieren. Weil wenn man sich damit ein bisschen beschäftigt, findet man halt immer oft so die Fragen, hey Stefan, wie flaky ist denn Playrate?

34:43Schepp Ist Playrate flaky wie Selenium oder Cypress und was sind denn die Probleme? Also ich kenne mich jetzt nur zwangsläufig irgendwie oder ich mache jetzt nur Playrate seit zwei, drei Jahren. Playwright hatte bisher in meinen Fällen immer recht. Wenn irgendein Test neun von zehn Mal funktioniert und einmal funktioniert es nicht, dann ist es nicht die Schuld vom Automatisierungsframework.

35:06Schepp Es ist grundsätzlich irgendeine Race Condition, irgendein Edge Case, oder dass meine Tests halt nicht so geschrieben sind, wie sie geschrieben sein sollten.

35:14Vanessa Oder dass die Seite tatsächlich kaputt ist.

35:16Schepp Oder sie war wirklich kurz kaputt, ja. Also diese Diskussion, hey, wie flaky ist diese Testing Framework? In meiner Erfahrung nach liegt es nicht am Framework. Das liegt so gut wie immer an. Gibt es einen wirklichen Grund?

35:30Vanessa Das heißt also, weiß ich nicht, so Web-Driver-befeuerte Lösungen oder irgendwie, weiß ich nicht, welche es noch gibt, die leiden tatsächlich an Flakiness, also quasi irgendwie an einem Kommunikationsproblem quasi aus dem Web-Driver und dem ferngesteuerten Browser zum Beispiel. Und dann kacken die einfach ab und sind weg.

35:57Vanessa Und das wäre so eine Flakiness. Oder gibt es noch andere Flakinessen?

36:06Schepp Also in diesem Fall, dass irgendwie Playrate, egal ob jetzt Library oder Testing-Frame, irgendwie Probleme hat, mit dem Browser zu kommunizieren, habe ich tatsächlich noch nie irgendwie wahrgenommen. Die Flakiness-Sachen, die ich halt regelmäßig sehe, es gibt halt mehrere Probleme. Ich kann mal einfach drauf losprabbeln. Ein Problem ist halt ganz oft, dass Leute halt ein End-to-End-Testing-Framework wie Cypress oder Playwright einbauen und dann ganz, ganz schnell dahin kommen zu sagen, hey, mein End-to-End-Testing-Framework oder meine Library, die ist zu schnell.

36:40Schepp Sie klickt den Button zu früh. Und das ist letztendlich ein ganz spannendes Thema, weil wenn man Playwright-Skripte schreibt, funktioniert der ganze Kernansatz, dass man sich auf Auto-Waiting verlässt. Und die Playwright-Actions und Assertions haben tatsächlich unglaublich viel Magic-Build-In. Das heißt, wenn ich mir jetzt einen Locator aussuche, Get by Roll Button, wo dann Kaufen drinsteht und ich möchte den klicken.

37:11Schepp Was nicht passiert ist, es passiert nicht, dass ich dann zum Playwright sage, hey, klick mal diesen Button jetzt sofort. Was passiert, wenn ich halt Klick aufrufe, ist, dass Playwright sogenannte Actionability Steps ausführt, die an einem Timeout hängen. Und wenn ich sage, ich möchte das jetzt klicken, wird Playwright halt warten und warten und warten und warten, bis dieser Button, der diesen Locator trifft.

37:34Schepp Enabled, visible, dass er nicht animiert ist, dass er nicht hidden ist, dass er unterm Overlay ist. Das heißt, ich muss mich gar nicht damit auseinandersetzen, was auf meiner Website passiert. Alles, was ich sagen möchte, ist, hey, klick diesen Button. Irgendwann. Natürlich habe ich irgendwie Timeouts, die ich definiere, Action-Timeouts, Assertion-Timeouts.

37:51Schepp Und man hangelt sich dann aber letztendlich nur von UI-State zu UI-State. Ich möchte jetzt diesen Button klicken. Mir ist total egal, wann der auftaucht, drück ihn. Und dann möchte ich, dass diese Headline mit diesem Text irgendwann visible ist. Spielt es eine Rolle, ob da ein Ajax-Call in der Mitte war?

38:07Schepp Ich würde sagen, höchstwahrscheinlich nicht, weil vielleicht verändert sich die URL, vielleicht wird die Funktionalität irgendwann vom Entwickler, Entwickler irgendwie angepasst. Und das sind dann diese Szenarios, wo Playwright natürlich unglaublich schnell ist. Wenn ich jetzt sage, hey, klick mal diesen Button, dann macht Playwright das sofort, wenn dieser Button available ist und enabled ist.

38:26Schepp Und gerade, wir haben 2025, die Frameworks sind alle ganz vorne, wir machen alle auch richtig heavy JavaScript und wir versuchen, gute Performance rauszuschieben. Und was ist mit diesen Applikationen, die wir halt beispielsweise Server vorrendern oder statisch vorrendern? Die sind halt irgendwie kaputt am Anfang, bis das JavaScript reinkommt.

38:48Schepp Das sind halt so diese pure Hydration Patterns, die wir halt überall im Netz sehen, dass irgendwie wir Webseiten ausliefern, die irgendwie funktional aussehen, aber letztendlich doch nicht sind. Und wir merken das jetzt wahrscheinlich nicht. Also ich sitze hier zu Hause in meinem schnellen Wi-Fi, an meinem MacBook.

39:03Schepp Das funktioniert schon alles so. Und ich klicke jetzt auch kein Button nach 0.1 Sekunden. Playwright drückt aber den Button. Weil Playwright denkt, hey, da ist ein Button, der ist enabled. Und das ist dann halt so ein anderes Feature. Das ist halt mega cool. Weil das zeigt letztendlich...

39:22Vanessa Das ist das jetzt, also dieses Szenario, was du gerade beschreibst, kann Playwright das, also läuft Playwright dann da auch rein jetzt oder schafft es das, doch tut es. Okay, also wenn es erst mal quasi nur ein Dummy ist, aber im Grunde leblos, weil das JavaScript halt noch nicht initialisiert ist und da ist und damit noch nicht klar ist, was denn überhaupt folgt auf den Button-Klick, dann würde Playwright, hätte das da auch nicht irgendeine Magic-Methode zu wissen, aha, den Button, den klicke ich besser noch nicht.

39:57Vanessa Der ist ja noch überhaupt gar nicht mit Events versehen oder so.

40:00Schepp Genau, das ist dann halt die Frage, wie löst du dieses Problem? Weil wenn wir jetzt diesen Button nehmen, der ja gut aussieht, aber noch nichts macht, wissen wir ja letztendlich nicht, wann das JavaScript reinkommt. Das ist ja ein Implementierungsdetail, wo sich die Leute draußen jetzt auch nicht zwangsläufig eine Platte machen.

40:19Schepp Kein Mensch irgendwie, ich meine, wir kennen all rage clicking. Und manchmal, vielleicht sitzt du in der deutschen Bahn und das dauert 15 Sekunden, bis der Button funktioniert oder kommt nach zwei. So, du könntest jetzt natürlich anfangen, irgendwie mit Playwright irgendwie zu gucken, wann ist ein JavaScript-Bundle da oder wann ist, um irgendwas in der Implementierung irgendwie abzufangen, um dann diesen Button zu drücken.

40:40Schepp Das ist ein Weg, das zu tun. Ich würde sagen, ein bisschen schwierig, weil jetzt gehst du ja auf die Implementierungsdetails. Ein anderer Ansatz ist irgendwie vielleicht die UI vielleicht ein bisschen anzufassen, sodass vielleicht am Anfang das Formular halt ein Disabled Button hat oder dass irgendwo steht, dass das jetzt hier gerade noch in flight ist oder dass irgendwo nur ein Spinner zu sehen ist, der ja auch nur dem User, der Userin irgendwie anzeigt, hey, das Ding ist hier noch nicht fertig, aber wir sind gleich soweit.

41:07Schepp Dann könnte man sich zumindest ranhängen und sagen, hey, wenn dieser Spinner nicht mehr da ist, dann drück mal diesen Button. Das würde ich halt sagen so UI fixen, weil wir wissen halt nicht, ob die Leute, die auf unserer Webseite rumhängen, gerade im ICE hängen, weil dann wird es rather painful. Ein anderer Ansatz, um das irgendwie zu lösen, ist auch deine eigenen Retry-Mechanismen irgendwie zu implementieren.

41:28Schepp Ich könnte jetzt ja auch sagen, ich drücke einen Button und ich erwarte, dass herzlich willkommen erscheint. Und wenn das nach drei Sekunden nicht passiert ist, dann drücke ich den Button halt nochmal. Und dann drücke ich halt nochmal. Und dann drücke ich mal nochmal. Das ist so für mich der Weg, den ich gehe, wenn ich jetzt nicht zwangsläufig auch auf der Implementierungsseite sitze, wo ich jetzt nicht zwangsläufig immer Bock habe, hier irgendwie ein Ticket zu schreiben und sagen, ihr habt hier pure Hydration im Frontend.

41:49Schepp Können wir das ja mal ein bisschen anpassen? Weil je nach Team, Trifft man da auf offene Ohren oder nicht so offene Ohren? Weil haben ja alle schnelles Internet. Ich denke aber schon, dass das, ich glaube, der Jake Archibald nannte das irgendwie, Lying Frontend oder so, das gab es einen Term vor. Das sind halt Frontend, ich denke, das ist halt schon irgendwie ein Architekturfehler.

42:11Schepp Wenn wir halt Frontend shippen, was gut aussieht, aber nichts macht. Und wenn man sich dann dahinter...

42:16Vanessa Das ist ja mit Versprechen sozusagen versehen, so ein Knopf, der nicht disabled ist. der verspricht ja etwas zu tun, wenn du ihn klickst. Und das ist ja schon sozusagen falsch. Also wenn er das nicht in der Lage ist, einzulösen das Versprechen, dann sollte er eben einfach disabled sein, bis er in die Lage versetzt wird.

42:38Schepp Ja, oder du hast halt ein Progressive Enhancement Approach oder irgendwas. Letztendlich ist ja schon der Ansatz hier, hey, du hast das Network in der Mitte. Du weißt nie, wie lange das dauert, bis dein JavaScript da ist. Und wenn du halt End-to-End-Skripte irgendwie schreibst oder Tests schreibt, die halt darauf beruhen, wir machen das so schnell wie möglich, weil letztendlich willst du ja deine Tests auch, dass die schnell laufen.

42:57Schepp Du willst ja, dass die jetzt nicht irgendwie auf jeden Network Call irgendwie warten oder irgendwie bis so eine SPA irgendwie kann manchmal auch 2, 3, 4, 5 Sekunden dauern, bis alle Network Calls irgendwie durchgelaufen sind, die ja natürlich auch einen Waterfall irgendwie darstellen. Du willst ja auch, dass das schnell läuft. Aber das finde ich ist halt so ein schöner kleiner Ansatz dann, dass in diesen Situationen merkst du dann halt, wo du all diese Pattern erst drin hast.

43:19Schepp So und das, weil das hat man ja zwangsläufig nicht auf dem Schirm, weil selbst wenn ich ja jetzt, äh, entwickle und ich hab dann irgendwie 3G, Network Throttling irgendwie in meinen DevTools offen, ich drück den Button jetzt auch nicht nach 0.1 Sekunden, so, das wird auch nicht passieren. Aber das sind so diese kleinen, schönen, kleinen Gimmicks, wo ich halt sag, ja, ja, cool, disable ich doch jetzt mal erst bei dem Button oder mach dir hier noch eine kleine Rating Message irgendwie drüber und dann ist die Applikation ein bisschen besser.

43:47Schepp Und das sind so diese kleinen Feature-Sachen, die dann freue ich mich immer. Dann ist das halt eine gute Sache.

43:54Vanessa Ja, klingt auf jeden Fall gut und sinnvoll.

43:57Schepp Ja, und das sind dann halt so diese kleinen Momente, also wie gesagt, ich kann das nur wiederholen, so Auto-Waiting, UI-First, UX-First, das sind so diese kleinen Sachen, wo man halt als Entwickler, Entwicklerin wirklich auch merkt, ja, hier kann ich noch was ausbessern, Playwright ist definitiv nicht zu fast oder nicht zu schnell, da gibt's halt ein Problem in der Applikation oder mein HTML ist irgendwie nicht cool oder man, es gibt halt so viele Vorteile einfach nur, wenn man sich damit ein bisschen auseinandersetzt.

44:17Schepp Es ist so ein bisschen ähnlich wie, wenn man anfängt, halt Unit-Tests zu schreiben, weil wenn man Unit-Tests zum ersten Mal schreibt, dann fängt man auch zum ersten Mal wirklich zu, was passiert denn, wenn ich jetzt das mache und das mache und das mache und das hat halt für mich so wirklich einen großen Wulst an Vorteilen, wenn ich halt erstmal anfange, irgendwie ein UI-Feature zu testen, dass dann halt so viele Sachen rausputzeln, die einfach zum besseren Produkt führen.

44:38Vanessa Ja. Cool. Genau. Und dieses Auto-Waiting, du hast ja schon erwähnt, das ist im Grunde einfach, weiß ich, das ist wahrscheinlich Promise-basiert oder irgendwie sowas in der Art. Und das löst eben das Problem, dass HTML vielleicht reingestreamt wird und unterschiedlich schnell und man eben einfach nie weiß, wann genau ist ein Element da, auf das man wartet.

45:06Vanessa Und da kann man einfach dann eben sagen so, hey, guck, halt halt Ausschau. Und wenn es denn dann da ist und die ganzen Bedingungen erfüllt, über die wir eben gesprochen haben, dann geht es weiter.

45:18Schepp Genau, und das basiert halt auf zwei unterschiedlichen Ansätzen. Es gibt halt die Locators und Actions. Beispielsweise, wenn du klickst, wird automatisch geguckt, ob das überhaupt möglich ist. Und dann gibt es aber auch noch die andere Seite, was dann halt Assertions sind. Das ist sowieso alles Promise-based.

45:32Schepp So Playwright-Code ist very wait, wait, wait, wait, wait, ne, überall. Aber dann gibt es halt noch die andere Seite, das sind halt die sogenannten Web-First Assertions, das sind dann halt, du gibst halt ganz klassisch Expect irgendwas und dann kommen dieselben Prinzipien halt wieder rein, dann hast du halt beispielsweise ein To Be Visible, dann wirst du schon wieder am Anfang irgendwie dazu gezwungen, okay, was habe ich denn jetzt hier für eine Accessible Role, dann musst du schon überlegen, okay, habe ich jetzt eine Heading, okay, was steht jetzt da drin?

45:58Schepp Und dann ist halt auch der Kernunterschied wieder, und das machen tatsächlich unglaublich viele, oder nicht unglaublich, aber relativ viele Leute machen das halt falsch. Es gibt halt zwei unterschiedliche Methoden und zwei unterschiedliche Ansätze in Playwright. Du könntest jetzt beispielsweise sagen, ich habe jetzt ein Locator-Heading sowieso und du fragst halt, hey, ist das jetzt Visible?

46:16Schepp Und das ist halt, ist Visible in einem Moment. Wirklich fragst du, ist das jetzt gerade da? Und dann gibt es halt die Web-First-Assertions, die halt da rangehen mit Expect und dann gibst du halt dein Locator rein und dann hast du halt To Be Visible. Das ist dann halt wieder die Zeitspanne. Du definierst wirklich nur, wo du ankommen möchtest, in welchem UI-State.

46:34Schepp Und das ist halt dann der Weg, irgendwie dich da langzuhangeln, um irgendwie zu sagen, hey, Playwright, I don't care what happens in the middle. Hier, ne? Mach mal einfach dein Ding. Solange, wenn hier der Button klickbar ist und die Heading irgendwann sichtbar ist, bin ich zufrieden. So, und das ist halt der Weg, irgendwie voranzugehen, um halt so wenig Flakiness wie möglich in den Test zu haben.

46:56Schepp Coole Sache.

46:58Vanessa Dennoch gibt's ja wahrscheinlich dann irgendwie so ein Upper Limit, so ein Timeout, wann er dann irgendwie beschließt, so jetzt schmeiß ich hin, jetzt wird das wahrscheinlich nichts mehr und das ist wahrscheinlich dann auch konfigurierbar, oder?

47:10Schepp Genau, du hast halt Timeouts auf Test-Ebene, auf Action-Ebene, auf Assertion-Ebene, du kannst auch alles überschreiben, wenn du halt möchtest, sodass, also der Player hat mehrere Level-Configuration-Approach, also du kannst alles über die Kommandozeile überschreiben, du kannst alles in der Playred-Konfig definieren und wenn du Lust hast, kannst du es pro Test oder pro Methode konfigurieren.

47:32Schepp Also wirklich so, wenn du mal einen langsamen API-Call hast, der irgendwo hängt, musst du jetzt nicht die ganzen Tests hochschreiben. Das ist tatsächlich so ein bisschen so ein Fingerspitzengefühl, natürlich möchte man jetzt auch schnell sein, so wann ist ein Test so langsam? Aktuell, die aktuelle Playred-Version, die lockt in die Konsole, wenn ein Test länger als 30 Sekunden dauert, dass es ein langsamer Test ist.

47:54Schepp Weiß ich nicht. Meine Tests sind auf jeden Fall länger als 30 Sekunden, aber ist alles konfigurierbar.

48:01Vanessa Ja gut, das ist wahrscheinlich einfach so ein bisschen so ein Ansporn, die Tests so zu schreiben, dass sie vielleicht irgendwie schneller gehen oder vielleicht auch ein Ansporn, das, was man testet, schneller zu machen.

48:13Schepp Genau, letztendlich ist ja, wie wir vorhin schon kurz besprochen haben, die Länge der Tests ist ja letztendlich das Bottleneck, weil wenn die Tests ja kurz sind, wenn die Tests 30 Sekunden sind, kann ich das Ganze ja mit Compute irgendwie lösen. Lokal ist natürlich, meine Hardware ist jetzt irgendwie limitiert, aber wenn es jetzt in GitHub Action oder GitLab Runners oder wo auch immer das nachher in der CI-CD-Pipeline läuft, kann ich mir ja hochziehen, was auch immer ich möchte.

48:36Schepp Die 30 Sekunden sind ja dann mein Limit. Wenn ich jetzt einen 6-Minuten-Test habe, dann ist es 6 Minuten wahrscheinlich so der Cut-of-Time. Deswegen, kurze Tests spielen schon eine große Rolle.

48:47Vanessa Naja, genau. Es gibt ja auch diese Testing-Pyramide und da sind ja dann End-to-End-Tests auch quasi so die, von denen es dann am wenigsten gibt, weil das natürlich auch irgendwie am längsten dauert und am ressourcenintensivsten sind. Und wenn man da irgendwie das schafft, durch etwas Überarbeitung irgendwie Zeit zu gewinnen, dann ist das schon eine Menge.

49:10Schepp Ja, ja, absolut. Und wenn wir uns halt irgendwie in den CI, CD-Bereich irgendwie bewegen, dann gibt es halt noch so ein ganz kleines Schmankel, was ich halt immer noch irgendwie beeindruckend finde. Also normalerweise fängst du ja an und du setzt jetzt deine, also ich ignoriere den Scraping-Teil so ein bisschen, weil das ist, schreibst du ein Node.js-Skript, gehst auf eine Webseite, machst irgendwas so, fertig.

49:32Schepp Für den End-to-End- oder UI-Test-Case funktioniert das Ganze halt so, du wirst schon deine Tests schreiben, die lässt du ja dann lokal laufen. Dann möchtest du ja auf jeden Fall irgendwie, dass die in deinen Pull-Requests, in deinen Merge-Requests irgendwo laufen und dann halt irgendwas blockieren, falls irgendwas kaputt ist.

49:47Schepp Weil Regressions haben wir alle mal irgendwann irgendwie, waren wir mal schuldig, sagen wir mal so. Und dann hast du irgendwie, läufst du relativ schnell in dieses It-Works-on-my-Machine-Problem. Und das wird natürlich noch schwieriger, wenn NotMyMachine ist jetzt nicht hier mein Kollege und meine Kollegin, die hier neben mir sitzt, wo ich mal rüberrollen kann, sondern das ist das Datacenter von GitHub, was irgendwo steht.

50:14Schepp Für dieses Problem gibt es halt Playwright Tracing. Das heißt, wenn jeder Testcase in Playwright durchläuft, nimmt Playwright alle Actions, alle Sachen, die in diesem Testcase, in dieser Browser Session irgendwie passiert sind, nimmt das Ganze auf. Und das ist so ein bisschen ähnlich, wie wenn wir jetzt eine Webseite entwickeln und wir haben halt die Chrome DevTools oder die DevTools of Choice oben, sodass wir halt Network Waterfall haben und hier das haben und so.

50:38Schepp Und man hat dann halt eine ähnliche UI. Das heißt, wenn jetzt meine Tests in CICD laufen, dann kann ich mir halt ein Zip-File nachher runterladen und ich habe halt einen roten Test gehabt und dann sehe ich halt all meine Actions, ich sehe alle Network Waterfalls, ich sehe Screenshots von allen möglichen Status oder was auch alles passiert ist unterwegs und dann sehe ich halt alle meine Actions.

50:57Schepp Und was denn wirklich irgendwie wild ist, man hat dann halt ein kleines Fensterchen, man kann das halt so, man geht zu trace.playwrite.dev, da droppt man dann halt diese Zip-File rein, dann sieht man alle Actions. Und das ist tatsächlich wirklich wild, als ich das zum ersten Mal gesehen habe, dann hast du halt auf der rechten Seite so ein bisschen so eine Live-Preview von der Webseite, die du ja gerade getestet hast mit all den Actions.

51:20Schepp Und Playwright, wenn du Tracing an hast, was du höchstwahrscheinlich in CICD haben willst, weil sonst kannst du das nicht debuggen, sonst läufst du halt in eine, okay, das Element war nicht visible oder sowas, Meldung. Playwright wird auf jeder Assertion, auf jeder Action halt einen Live-Dom-Snatch-Shot machen und den auch inkludieren.

51:38Schepp Das heißt, wenn dann irgendwas fehlt, kannst du halt wirklich hier, das ist alles in deinem HTML, machst du auf in deinem Browser und dann kannst du wirklich sehen, okay, hier hatte diese Webseite irgendwie diesen Zustand. Und hier fehlen die Klassen und hier fehlt das und das, sodass man das halt live debuggen kann.

51:51Vanessa Okay, das heißt, der macht nicht einen grafischen Screenshot, oder macht den auch, aber er macht vor allem, grabbt er quasi einen Snapshot des HTML, des DOMs in dem Moment und packt das da auch mit rein.

52:06Schepp Ja, für jede Action. Das heißt, du kannst halt wirklich Stück für Stück durchsteppen, welches HTML war denn in meiner Webseite, als jetzt hier das geklickt wurde, als das irgendwie to be visible war. und dann kannst du dich durcharbeiten. Dann guckst du noch ein bisschen ins Network-Waterfall. Was war hier?

52:20Schepp Was ging in der Konsole ab? So cool. Und das ist halt so, als ich das zum ersten Mal so wahrgenommen habe, das Works on My Machine, ist halt so, ja, ne, dann lädst du halt das Trace-File runter und guckst, was abging. Und das ist so, von der Developer-Experience ist das so ... Gute Sache, finde ich richtig gut.

52:39Vanessa Ja, so ein bisschen im Grunde wie der Chrome-Profiler, der ja auch unfassbar viel Infos hat und wo man eben auch gucken kann, so da wurde das geladen und dann wurde folgendes JavaScript ausgeführt und man das alles so miteinander, also alles zusammen irgendwie verknüpfen kann und dann irgendwelchen Merkwürdigkeiten auf die Spur kommen kann.

53:05Schepp Ja, und das sind dann halt so die Situationen, dann hast du halt einen fehlenden Test, gerade wenn du halt ein gut laufendes Development-Team hast, dann hast du wahrscheinlich ganz, ganz viele Tests, die zeitgleich auf irgendwelche Preview-Environments feuern oder vielleicht auf Production, je nachdem, wo du deine Tests halt laufen lässt.

53:20Schepp Und das sind dann halt so die Momente, also ich habe jetzt, wir alle glaube ich, einen starken Frontend-Background, das sind dann so die Momente, wo dann lädst du halt das Trace-File runter und dann siehst du so, ah ja, dieser Endpunkt, der hatte hier irgendwie zweimal eine 500. Das sind so diese Sachen, die kriegst du nie bewiesen. Dann gehst du halt zu der Person, die halt die API implementiert. Nee, nee, meine API, nix.

53:42Schepp Gar keine Chance. Und dann reichst du halt das Trace-Fall runter. Und wenn du Glück hast, hast du da halt eine Amazon-Request-ID oder irgendwas dran und sagst, hier, guck mal da in deinen Logdix da. So, hier habe ich eine 500 gesehen. Viel Spaß. Da steht's. Da steht's. Und das sind halt so die kleinen schönen Momente, wo wir so, naja.

53:57Schepp Und wie gesagt, meistens hat Playwright recht. Also ich konnte noch nicht sagen, okay, hier ist jetzt ein Bug.

54:04Vanessa Ja. Ja, sehr geil. Cool. Also echt klingt nach einem super Tool. Genau, ich habe es, wie gesagt, auch nur so mal oberflächlich und dann auch eher so für Automatisierung benutzt. Ich glaube, ich habe es auch benutzt, weil das, glaube ich, so ein quasi so ein Winkelzug ist, mit dem man ein Webkit auf Windows laufen lassen kann.

54:28Vanessa Das geht über Playwright, das ist ganz cool. Das geht ja schon lange, lange, lange nicht mehr seit Safari 5.

54:36Schepp Seit Safari 5, das ist wirklich schon lange.

54:39Vanessa Ja, genau. Also ich glaube, Safari 5.1 war die letzte Version für Windows. Genau, jetzt bin ich ja mittlerweile auch auf Mac gewechselt und habe das Problem nicht mehr. Aber als ich auf Windows war, war das immer so. Also Browser-Stack gibt es natürlich auch noch.

54:51Schepp Das wollte ich letztens versuchen. Das war so login-gated. Und dann habe ich irgendwann aufgegeben, weil da war sofort Kreditkarte, hier Stefan. Und dann habe ich gesagt, nee, hier komm.

54:59Vanessa Ja, genau, das habe ich schon. Also das ist leider auch nicht so ganz billig.

55:05Schepp Genau, also ich bezahle sehr gerne für Software, wenn ich die wirklich benutze, aber das war so ein Betrag, wo ich dann gesagt habe, hey, hey, ich will hier kurz mal Windows. That's it.

55:15Vanessa Verstehe ich, genau, ich Ich baue es auch nicht, es gibt auch so Zeiten, da baue ich es nicht, aber manchmal gibt es so Zeiten, da benutze ich es schon, da ist es schon super. Genau, und dann lohnt es sich irgendwie doch. Ja, aber auf jeden Fall Playwright, super cool. Also wir haben das auch bei uns im Projekt, nur mache ich das nicht und wir haben da auch End-to-End-Tests, die in der GitLab-Pipeline dann laufen und so und die auch reichlich Regressions immer finden und abfangen oder wenn irgendwie auch teilweise Content editiert wird, dann schlagen die an und sagen, hier ist aber irgendwas Fouls nicht mehr wie vorher und dann so, ah, okay, das war gewollt, gut, wir passen die Tests an.

55:59Schepp Das ist, glaube ich, noch ein Punkt, den man kurz erwähnen könnte. Visual Regression Testing ist automatisch built-in in Playrate, wenn man darauf Bock hätte, weil du gerade Content changes, das ist so ein bisschen, wenn man darauf Lust hätte. Ich bin da ehrlich gesagt ein bisschen skeptisch, wenn es zu Visual Regression Testing angeht, weil das macht ganz schnell relativ, Große Probleme, weil beispielsweise ich bin jetzt auf dem Mac unterwegs, wenn meine CI-Tests dann in einer Linux-Umgebung laufen, dann fehlen vielleicht irgendwelche Schriften und dann ist hier ein Pixel falsch und dann begibt man sich relativ schnell.

56:36Vanessa Ja, die Schriftglättung ist ja dann immer die Schrift, die Antilizing-Mechanismen sind pro OS dann wieder anders und dann brauchst du so einen Threshold, ab dem der erst anschlagen darf. Ja, genau, das sind nur die klassischen Visual Regression-Testing-Probleme, die eigentlich auch noch nie richtig gelöst wurden.

56:54Schepp Ja, die Lösung da ist halt, wenn man darauf halt Lust hätte, könnte ich halt mir einen Docker hochziehen und könnte halt irgendwie Playred im Docker laufen lassen, sodass es uns hier ... Da bin ich schon so, naja, vielleicht ist es auch nicht so wichtig. Ist aber Build-In für alle Leute, die darauf Bock haben. Wenn man ja vielleicht nur lokal laufen lässt, dann ist es, glaube ich, schon cool, wenn ich jetzt weiß, ich möchte jetzt wirklich nur mein Chromium hier auf meinem Mac laufen lassen.

57:19Schepp Aber sobald es in CI unterschiedliche Geräte, macht man da sehr, sehr schnell Can of Worms auf.

57:25Vanessa Ja, aber wir könnten da ja unsere Hörerinnen und Hörer mal fragen, nutzt ihr Playwright und nutzt ihr dann in Playwright das Visual Regression Testing? Und wie ist denn euer Setup? Und wie habt ihr eben genau diese Probleme, die man so hat? Elegant, möglicherweise elegant umschifft. Genau, also ihr wisst, wie ihr uns findet.

57:49Vanessa Mittlerweile könnt ihr ja auch suchen nach unserem Slack auf unserer Seite. Aber genau, wir werden auf jeden Fall auch Stefans Kontaktwege mit verlinken. Genau, weil ich könnte mir vorstellen, dass du da ja als Playwright ja, Instanz, ich weiß nicht, du heißt es nicht sogar Ambassador oder sowas?

58:10Schepp Ja, es gibt ein Programm, Player Ambassadors, bin ich mit reingestolpert.

58:15Vanessa Tatsächlich. Ich unterstelle dir mal, dass du da auch interessiert dran bist.

58:18Schepp Immer, immer gerne.

58:21Vanessa Genau. Dann vielleicht noch abschließend die Frage, wenn man Blut geleckt hat nach dieser Folge, wo, würdest du sagen, ist die beste Anlaufstelle, also neben dem CodeGen-Feature, aber wo man irgendwie Doku oder quasi irgendwie so einen Kickstart bekommt?

58:40Schepp Ja, wie immer, PlayRate Docs natürlich, vorn ran. Ich habe aber auch die Ehre, falls Leute mir zuhören wollen, für ein Berliner Unternehmen, das nennt sich Checkly, nehme ich YouTube-Videos auf, PlayRate Education. Das heißt, einmal die Woche, spätestens alle zwei Wochen, release ich ein YouTube-Video, was halt beinhaltet neue kleine Tricks von PlayRate, meistens fünf Minuten, zehn Minuten.

59:05Schepp Ich habe jetzt auch angefangen mit YouTube-Shorts, das ist mir unglaublich suspekt, aber funktioniert sehr gut. Aber für Leute, die YouTube Playwright-Content Bock haben, alle zwei Wochen gibt's was Neues. Und für den offiziellen Kanal Playwright-Discord, letztendlich. Sehr aktive Community. Guter Ort.

59:28Schepp Ich sehe, dass relativ viele Leute auf Sack-Overflow-Playwright-Fragen irgendwie publishen und posten. Wenn ich wirklich stuck bin, würde ich immer Discord vorziehen. Und letzter Kanal ist, das Playwright-Team hat eine Issue-Answer-Time von einem Tag. Das heißt, sie versuchen wirklich, die GitHub-Issues zu kuratieren und zu beantworten.

59:56Schepp Muss man sich aber natürlich damit auseinandersetzen, dass man halt einen Test, also was Testbares hat. Ein Hey geht nicht, wird wahrscheinlich nicht funktionieren, dann kriegt man das erste Mal ein HTML-Schnipsel, wo das jetzt wirklich so ist, kriegt man das relativ schnell zurück.

1:00:14Vanessa Ja, klar. Aber das macht ja, es ist ja bei Issues aufmachen generell, also würde ich jetzt erwarten einfach, also dass man den Leuten die Möglichkeit gibt, das irgendwie nachvollziehen zu können mit oder an einem Testcase oder sowas.

1:00:31Schepp Genau, ich meine, du musst halt ein Testcase zur Verfügung stellen plus und oder halt ein Trace-File, je nachdem. Funktioniert jetzt natürlich nicht für jeden Store, weil Zip-File inkludiert wahrscheinlich Cookies und Session-Daten und so eine Sache. Aber fand ich auch sportlich. Aber offizielle Ansage ist, glaube ich, ein Tag immer noch gute Sache. Hut ab.

1:00:52Vanessa Sehr, sehr cool. Haben wir sonst noch vergessen, was wir noch verlinken wollen? Genau, deinen Newsletter, den Webweekly, den verlinken wir auf jeden Fall. Du kannst da auch gesponsert werden, beziehungsweise gepatrionisiert werden.

1:01:07Schepp Genau.

1:01:09Vanessa Tut das auf jeden Fall. Genau, weil ich finde, es gibt halt wenig solche tollen Newsletter und du steckst ja auch wirklich viel Zeit da rein, ne? Du hast das, glaub ich, mal irgendwo, du hast das mal in einem Blogpost aufgeschrieben.

1:01:23Schepp Ja, na ja. Ich mein, ihr seid ja auch Content Creators. Kostet immer mehr Zeit, als man denkt, ne? Weekly ist, also Schreiben kostet mich, weiß ich nicht, sechs, sieben Stunden pro Woche. Das ist schon viel. Und ich habe halt schon irgendwie so den Anspruch jetzt nicht. Also es gibt halt wirklich gute Frontend Newsletters out there.

1:01:46Schepp Aber ich möchte halt schon irgendwie, man muss sich ja schon auch irgendwie differenzieren, wenn er will. Und ich möchte halt schon so Platform First, kleine Details über HTML, CSS. Und die fliegen ja jetzt nicht so einfach hier durch meine Tür durch.

1:02:00Vanessa Ja, deswegen ist das ja auch so ein Unikat. Also es gibt wirklich wenig vergleichbares, also vielleicht noch Webplattform News gab es mal. Ich weiß noch nicht, ob die noch aktiv sind.

1:02:10Schepp Er hat aufgegeben, der Schime. Ich hab mich, glaube ich, mal länger mit ihm unter... Fand ich nämlich auch von der Bombe. Da kam dann... Wurde halt auch immer unregelmäßiger. Aber er hat halt schon so ein... Hier ist die Spec und hier ist der Bug und hier ist das. Und deswegen fußt er uns so, wow, wo holst du das alles her?

1:02:30Schepp Der war ganz tief drin und wüsste alles.

1:02:31Vanessa Ja.

1:02:32Schepp Der hat aber aufgegeben, tatsächlich.

1:02:34Vanessa Ja, okay. Genau, und das wollen wir ja nicht, dass du das auch noch tust. Weil dann haben wir ja gar keine solche Newsquelle mehr. Und deswegen unterstützt auch den Stefan, wenn ihr den Webweekly abonniert und gut findet.

1:02:47Schepp Und den Working Draft natürlich.

1:02:49Vanessa Und uns, genau. Und wo wir schon dabei sind, wir haben gedacht, wir müssen da auch mal wieder so ein bisschen das Game der Podcast-Plattformen spielen. Und das lautet, also damit wir da ein bisschen in den Ranglisten sind, weil wir jetzt mal gesehen haben, so, hey, Moment, Tech-Podcast, wieso tauchen wir da eigentlich nicht auf? Und ihr könnt es ändern.

1:03:12Vanessa Ihr müsst nämlich tatsächlich das Liken machen und dann natürlich auch euren Freunden sagen, dass sie uns subscriben sollen und vielleicht auch eine Rezension schreiben. Und das nennt dann immer so die Indikatoren für Apple Podcasts und Spotify und so, dass wir wieder so ein bisschen da in den Vorschlagslisten nach oben wandern. Genau.

1:03:38Vanessa Ja, dann sind wir durch. Vielen lieben Dank. Cool, dass du da warst. Das nächste Mal müssen wir vielleicht dann wieder nochmal einen Glücksrad machen, oder? Was hältst du davon?

1:03:47Schepp Sehr gerne. Random Web Facts. Dann bin ich am Start.

1:03:51Vanessa Sehr gerne. Genau, haben wir auch schon länger nicht mehr gemacht. Ich weiß gar nicht, wo wir das letzte Mal gemacht haben. Es wird wieder Zeit. Genau. Und ja, ansonsten, wie gesagt, ihr wisst, wo ihr Feedback lassen könnt. Und ich schaue nochmal schnell nach, ob ich sehen kann, was nächste Woche geplant ist bei uns.

1:04:11Vanessa Und das ist, na, nee, da wissen wir so, genau, das wird ohne Gäste sein. Und dann schauen wir einfach mal. Genau, also wir hatten mal geplant, vielleicht mal was zu 30 Jahre Self-HTML zu machen. Aber die Self-HTMLer haben wir noch nicht am Start. Das kommt dann wahrscheinlich noch. Genau, deswegen erzählen wir vielleicht was über, worüber ich heute das Blogpost geschrieben habe.

1:04:36Schepp Gute Sache.

1:04:38Vanessa Ja, cool. Dann vielen Dank, liebe Grüße nach Berlin, liebe Grüße aber auch nach Kiel. Danke zurück. Vielen Dank fürs Zuhören. Dann haben wir uns nächste Woche wieder. Bis denn.

1:04:49Schepp Danke, tschüss.

1:04:50Vanessa Tschüss.