{
  "video_id": "FWEInOtngmM",
  "channel_slug": "aidotengineer",
  "channel_handle": "aidotengineer",
  "title": "Beyond Code Coverage: Functionality Testing with Playwright — Marlene Mhangami, Microsoft",
  "duration_seconds": 1185.0,
  "url": "https://www.youtube.com/watch?v=FWEInOtngmM",
  "upload_date": "",
  "transcript": "Okay.\nHallo zusammen.  Ähm, mein Name ist Marlene und\nich bin Senior Developer Advocate bei\nMicrosoft und GitHub.  Ich arbeite\nin einer Gruppe namens Core AI, die\nuntersucht, wie Entwickler KI in\nunseren Produkten einsetzen.  Ähm, das ist also etwas\nNeues.  Zu Beginn möchte ich\nIhnen heute einige Statistiken über GitHub aus dem\nGitHub Octoverse-Bericht vom letzten Jahr zeigen,\nder\nDaten darüber enthält, wie Entwickler\nGitHub nutzen.  Unserem Bericht zufolge wurde im\nletzten Jahr mehr Code auf GitHub hinzugefügt\nals je zuvor.  Im Jahr 2025 wurden also rund eine\nMilliarde Commits auf die\nPlattform übertragen, was das\naktivste Jahr in der Geschichte von GitHub darstellt.  Okay.  Was wir heute,\nim Jahr 2026, wissen, ist, dass sich dieses Wachstum\nbeschleunigt.  Ein paar von uns haben zwar\nnoch keine offiziellen Statistiken veröffentlicht, aber vor ein paar Tagen twitterte unser COO,\nKyle Dagel, dass wir jede Woche\netwa 275\nMillionen Commits auf der Plattform verzeichnen\n.  Und wenn wir das im Laufe der\nZeit hochrechnen, werden wir\nbis Ende des Jahres etwa 14 Milliarden Zusagen sehen.   Das entspricht dem\n14-Fachen des Wachstums\nbzw. der Zusagen im Vergleich zum Vorjahr, das übrigens\nmit einer Milliarde Zusagen unser bisher erfolgreichstes Jahr war\n.  Eines wissen wir:\nEin wachsender Anteil dieser Commits wird\nvon KI-Agenten mitverfasst.  Wir\nhaben die Daten noch nicht veröffentlicht, aber wir\nkönnen tatsächlich nachverfolgen und sehen, dass\nbeispielsweise Claude Commits\nmitunterzeichnet, ebenso wie Co-Pilot, Codex jedoch\nnicht.  Wir können das aber auch anhand bestimmter\nFormulierungen im\nCode nachvollziehen.\nAls ich dieses enorme Wachstum sah, fragte ich mich,\nwie viel Code wir da eigentlich zu\nsehen bekamen.  Und die Frage lautet: Macht KI\nEntwickler tatsächlich\nproduktiver?  Wir sehen den gesamten\nCode.  Besteht tatsächlich ein Zusammenhang mit der\nProduktivität?\nEine der besten Quellen, die ich kenne und die\nversucht, diese Frage zu beantworten, stammt\ntatsächlich von einem KI-Ingenieur aus einem Vortrag im\nletzten Jahr.  Und diese Grafik präsentiert\nErgebnisse aus diesem Vortrag, die auf einer\nStudie der Stanford University mit 120.000\nEntwicklern basieren.  Und in dieser Studie wurde\nfestgestellt, dass KI zwar die\nProduktivität von Entwicklern steigern kann, aber\nletztendlich die Art und Weise, wie die Entwickler die KI einsetzen,\nam wichtigsten ist.  Dieses Diagramm\naus der Studie zeigt uns also, dass\nsaubere Codebasen die Vorteile und die Produktivität von KI steigern,\nwährend unkontrollierte KI in einer\nCodebasis die Entropie erhöht.\nUm diesen Punkt zu veranschaulichen, nannte der Redner\nin seinem Vortrag ein Fallbeispiel eines\nUnternehmens, das KI\nin seiner Datenbank unkontrolliert einsetzte.\nMan kann sehen, dass die Anzahl der Pull\nRequests, die das Team veröffentlichte, zwar\nzunahm, gleichzeitig aber die Codequalität\nabnahm und das Team viel\nmehr Zeit mit der Überarbeitung und dem\nRefactoring des Codes verbrachte.\nObwohl es insgesamt eine Steigerung der effektiven Leistung\num etwa 1 % gab,\nverbesserte die KI die Produktivität des Teams nicht wirklich.\nWas wir also aus dieser Studie gelernt haben, ist, dass ein\nGroßteil des Nutzens, den wir uns\nals Entwickler von KI erhoffen, auf\neiner sauberen Codebasis beruht.\nFür Entwickler, die KI-\nTools verwenden, wollen wir uns daher auf Aspekte wie\ngute Testabdeckung, Typabdeckung,\ngute Dokumentation,\nModularität usw. konzentrieren.\nIch würde daher auch argumentieren, dass wir damit\nbeginnen müssen, bestimmte Vorgehensweisen\nteamübergreifend und branchenweit zu standardisieren\n.  Und das ist ein etwas\nkontroverses Thema, denn\neinige Teilnehmer dieser Konferenz glauben, man müsse einfach nur die\nAugen verschließen und liefern lassen.\nUnd das ist auch in Ordnung.  Aber ich denke, in meiner\nidealen Welt und basierend auf dieser Studie, die wir\ngesehen haben, würde ich standardisierte\nVorgehensweisen zur Sauberhaltung einer Codebasis empfehlen.\nWie können Entwickler also\nsauberen Code erstellen und pflegen?  Diese Frage\nist eigentlich keine neue Frage.  In unserer\nBranche haben wir im Laufe der Zeit verschiedene\nMethoden gesehen, die versucht haben, die\nPflege einer sauberen Codebasis zu einem zentralen\nBestandteil ihrer Philosophie zu machen.\nEiner dieser Ansätze, über den ich\nviele Entwickler sprechen gesehen habe, die\nagentenbasiertes Codieren mit Coding-\nAgenten betreiben, ist die testgetriebene\nEntwicklung oder TDD.  Simon Willis,\nder sehr beliebt ist,\nhat vor Kurzem einen Blogbeitrag darüber veröffentlicht, wie er\ndiese spezielle Variante von TDD namens\nRed Green TDD verwendet.  Und dabei passiert Folgendes: Als Erstes\nerhält der Entwickler eine eingehende\nFunktionsanfrage.  Sobald sie die\nAnfrage erhalten, beginnen sie sofort damit,\neinen fehlgeschlagenen Test zu schreiben, weil die\nFunktion nicht existiert.  Danach\nkonzentriert sich der Entwickler darauf, den Test zum\nBestehen zu bringen.  Und in dieser grünen Phase, in der es darum geht,\nden Test zu bestehen,\nsollte man sich traditionell nicht\nauf die Qualität des Codes konzentrieren.  Du\nkonzentrierst dich nur auf Geschwindigkeit und darauf, dass der\nTest positiv ausfällt.  Früher\nkopierten Entwickler also vielleicht Code von\nStack Overflow und so weiter und schafften es trotzdem, die\nTests zu bestehen.  Aber danach folgt als\nletzte Phase die Refactoring-\nPhase.  In dieser Phase konzentrieren Sie sich ausschließlich\nauf die Codequalität.  Sie\nnehmen also den Code, den Sie bisher geschrieben haben, und\nüberarbeiten ihn so, dass er allen\nBest Practices entspricht.\nNicht jeder ist also ein Fan von TDD, und wie so vieles\nin dieser Branche wurde TDD\nim Jahr 2014 für tot erklärt.\nÄhm, und eine der häufigsten\nBeschwerden, die ich im\nInternet über TDD gesehen habe, ist, dass es sich\nzu sehr auf die Codeabdeckung mit Unit-\nTests konzentriert und das System selbst nicht wirklich testet\n.  DHH, der Entwickler von Rails,\nveröffentlichte diesen Blogbeitrag im Jahr 2014 und sprach darin im Grunde über die\nübermäßige Fokussierung auf Unit-Tests.\nUnd wir wissen, dass bei einer zu hohen\nCodeabdeckung verschiedene Probleme auftreten\n.  Eines der Probleme besteht darin, dass man dazu\nneigt, Implementierungsdetails zu testen\n.  Nehmen wir zum\nBeispiel das, was wir auf dem Bildschirm sehen, wo\nwir eine Bestellberechnung mit\nRabatt haben.  Wenn der Test direkt\nan eine Methode wie calculate gebunden ist, führt schon das einfache\nUmbenennen des Tests dazu, dass diese Unit-Tests nicht mehr funktionieren, selbst wenn\ndie Funktionalität weiterhin gegeben ist\n.  Das wird also nicht\ngut werden.  Selbst wenn wir\ngezielt das Verhalten des\nSystems testen, wie zum Beispiel das Endergebnis des\nPreises, den wir anstreben, oder wenn wir\netwas wie einen stabilen Vertrag\nwie unsere API oder ein Modul testen, das sich nicht\nändert, aber das wir exportieren, sollte es\nalle Refaktorierungen unseres internen Codes überstehen.\nWenn Sie\nmehr darüber und über\nverhaltensgetriebenes TDD erfahren möchten, empfehle ich Ihnen den\nVortrag von Ian Cooper mit dem Titel „TDD – Wo\nalles schiefging“.  Das ist ein sehr gutes Gespräch.   Eine\nweitere Beobachtung ist, dass im\nZeitalter der KI\nviele Entwickler KI zur\nGenerierung von Tests einsetzen. Dabei ist ihnen aufgefallen,\ndass die KI manchmal\nselbstbestätigende Tests generiert.  Auch wenn der\nCodeabdeckungstest erfolgreich ist und Ihre\nUnit-Test-Suite durchweg grüne Ergebnisse liefert,\nwird das Verhalten des Systems nicht\nvalidiert, und genau da liegt das Problem\n.   Im weiteren Verlauf\ndieses Vortrags werde ich mich darauf\nkonzentrieren, Ihnen zu zeigen, wie Sie\ndiese Probleme vermeiden und mit\nPlayright die Funktionalität testen können.\nPlayright ist ein Open-Source-\nTestframework von Microsoft, das\nEnd-to-End-Tests im\nBrowser automatisiert, indem es Benutzerinteraktionen simuliert.\nDer Link, den Sie dort auf dem Bildschirm sehen,\nist die Dokumentation.\nPlay unterstützt derzeit eine Reihe verschiedener\nSprachen, darunter Python, TypeScript\nund C. Das Beispielskript, das Sie\nauf dem Bildschirm sehen, zeigt, wie ein\ntypischer Test aussehen würde.  Sie haben also diese\nZeile, die sagt: \"page go to\", die\ndem Skript mitteilt, dass es auf der\nSeite \"toys pla\" beginnen soll. Dort wollen wir anfangen. Dann\nsuchen wir nach dem\nPlatzhalter \"search\" und\nfüllen die Suchleiste mit\ndem Buchstaben \"furby\". Dadurch wird\ndie Suche beispielsweise\nautomatisch im Browser ausgeführt.\nSie können auch den\nModus mit oder ohne Monitor verwenden.  Sie müssen also nicht unbedingt\nauf den Browser schauen, während Ihre\nTests laufen.  Man kann\nsie auch einfach im Hintergrund laufen lassen\n.\nÄhm, warum?  Okay.  Um auf die Idee\ndes testgetriebenen Lernens (TDD) zurückzukommen: Wenn wir Playright mit\nKI verwenden, sollte dies den gesamten\nTDD-Prozess für uns beschleunigen.  Viele\nEntwickler haben sich in der Vergangenheit darüber beschwert, dass\nTDD langsam sei und\nfür Teams,\ndie schnell vorankommen wollen, nicht effektiv.  Aber wenn wir\nKI haben, dann passiert Folgendes: Der rote\nund der grüne Teil bewegen sich schnell.  Wir konzentrieren uns also darauf,\nunsere Agenten dazu zu bringen,\ndiese Verhaltenstests, die\nPlayright-Tests, zu generieren.  Dann konzentrieren wir uns darauf,\nden Agenten dazu zu bringen, so\nschnell wie möglich Code zu generieren, der\ndie Tests erfolgreich durchführt.  Und dann würde ich\nempfehlen, dass die Entwickler\ndie meiste Zeit damit verbringen,\nin der Refactoring-Phase zu arbeiten, damit das Projekt größer wird.\nSie verbringen also Zeit damit, den vom\nAgenten generierten Code zu analysieren und ihn zu\nverbessern.\nEs gibt verschiedene Möglichkeiten, wie Sie\nIhre Coding-Agenten heute mit Playright verbinden können.\nEine dieser Möglichkeiten ist der\nPlayright MCP-Server.  Alternativ können Sie auch das\nCLI-Tool verwenden.  Oder\nSie können so etwas wie\nDramatikeragenten in Anspruch nehmen.  Und wenn Sie\nPlayrite-Agenten verwenden, führen Sie den Befehl aus,\nden Sie auf dem Bildschirm sehen können.  Und sobald\nSie diesen Befehl ausführen, werden\ndrei Agent-MD-Dateien für Sie installiert.\nDer erste wird also ein\nPlaner sein.  Der zweite ist ein Generator und der\ndritte ein Heiler.  Der Planer wird also\nfestlegen, welche Tests durchgeführt werden sollen.  Der\nGenerator erstellt\ndie Tests, und der Heiler korrigiert\ndiese dann für dich.  Okay.\nIch möchte Ihnen also eine Demo zeigen und\nhoffe, dass mir die Demo-Götter heute wohlgesonnen sind\n.  Äh, also ja, wir werden es\nversuchen.\nOh.  Oh nein.\nOkay.   Auf geht's\n.  Ich möchte Ihnen daher ein\nSzenario schildern.  Das Szenario ist folgendes: Du\nkannst mich nicht sehen,\ndu schaust dir gerade nur meine PowerPoint-Präsentation an,\nund ich weiß nicht, wie ich\ndas verhindern kann.  Äh, ich schließe vielleicht mal die PowerPoint-Präsentation\nund schaue, ob das hilft.   Ähm,\nich möchte nicht einfach nur diesen Bildschirm zeigen.\nEntschuldigung.\nHoffentlich geben sie mir mehr Zeit.\nOkay, perfekt.  Das funktioniert wie\nerwartet.  Okay, perfekt.  Das\nSzenario, das wir uns\nheute vorstellen werden, ist folgendes: Stellen Sie sich vor, ich bin ein Entwickler.  Ich\narbeite bei einem Spielzeughersteller namens Tail\nSpin Toys.  Und vor ein paar Tagen erhielt ich eine\nE-Mail vom Produktmanagement-\nTeam der Suchfunktion, in der ich gebeten wurde, einige neue\nSuch- und Filterfunktionen zur Website hinzuzufügen.\nSie baten mich, eine Suchleiste hinzuzufügen,\nmit der Option „Häkchensuche“ für einfache Suchanfragen und „\nAzure AI-Suche“ für komplexere Suchanfragen.\nUnd sie haben mich auch gebeten, eine\nSeitenleiste hinzuzufügen, damit Kunden nach\nKategorie und Preis filtern können.  Ich würde mich freuen, wenn\nCopilot mir bei dieser Aufgabe helfen könnte und\nwir außerdem diesen TDD-First-\nEntwicklungsstil anwenden würden.  Dies ist also die GitHub\nCopilot CLI, und als erstes werden\nwir versuchen, den\nAgenten dazu zu bringen, die Informationen\naus der E-Mail abzurufen und die Funktionen\nhier in unser Terminal einzubinden.  Und dafür werden\nwir etwas namens WorkIQ verwenden, das von\nMicrosoft entwickelt wurde. Es handelt sich um eine Funktion, mit der\nEntwickler eine Verbindung zur M365-Suite herstellen können.  Also\nOutlook, PowerPoint, was auch immer Sie\nbenötigen, und diese Informationen\nhier in das Terminal einbinden.  Wenn Sie also\ndie M365-Suite für die Arbeit nutzen, kann ich\nsie Ihnen auf jeden Fall empfehlen.  Und was ich in Bezug auf\nTDD in der Vergangenheit noch erwähnen möchte, wenn\nwir Dinge wie Unit-Tests durchgeführt haben, ähm,\ntypischerweise ist der Auslöser für das\nSchreiben eines Unit-Tests das Hinzufügen einer neuen\nMethode zu einer Klasse.  Doch in dieser\nneuen Welt wollen wir uns eigentlich auf\ndas Verhalten konzentrieren.  Wir wollen uns also auf ein bestimmtes\nMerkmal konzentrieren.  Wenn also eine Funktionsanfrage eingeht, ist dies\nder Auslöser dafür, dass der Test\ngeschrieben wird.  Jetzt haben wir also unsere Liste\nder Dinge, die tatsächlich entwickelt werden müssen,\nund ich gebe eine zweite Eingabeaufforderung hinzu\nund\nbitte Copilot, mir bei der Entwicklung dieser\nFunktionen mit Hilfe von Red Green TDD zu helfen, indem er zunächst\ndie Playright-Tests schreibt, die\nfür jede Funktion fehlschlagen, und ich weise ihn an,\ndie Änderungen nur für\ndieses Beispiel nicht zu committen.  Und ich möchte darauf hinweisen,\ndass der Agent als erstes mit der\nUntersuchung meiner Codebasis beginnen wird.  Es wird also\nverstehen, was sich in meiner Codebasis befindet.  Ich habe\nden Playright MCP-Server bereits\nin meiner CLI installiert, genauer gesagt in der Copilot\nCLI, und er weiß, was er tun muss, um\ndie Tests zu erstellen, mit denen er\ndiese Funktionen testen kann.  Der Agent wird also\nverstehen, wie die Codebasis\naussehen wird, und dann\ndie Tests dafür schreiben.  Äh, dieser Prozess wird\ntatsächlich eine Weile dauern.\nIn der Zwischenzeit wechsle ich also\nzu einem neuen Tab und führe\nden Befehl aus, um den\nPlayright-Test durchzuführen.  Also, heute Vormittag habe ich\nden Agenten gebeten,\ndiese fehlgeschlagenen Tests zu generieren, und dann habe ich ihn dazu gebracht,\ndie grüne Phase durchzuführen, in der der Agent einfach\nden Code erstellt, damit der Test bestanden wird\n.  Und jetzt bitte ich meinen Agenten,\nden Playright-Test durchzuführen, um die\nSuchleiste und die\nFilterfunktion für uns zu testen.  Wie ich\nbereits erwähnt habe, ist der Playright\nMCP-Server bei mir bereits installiert.  Sie können\nes hier installiert sehen.  Und unser Agent wird sich\neinfach die Testdatei suchen.\nUnd wenn alles korrekt funktioniert,\nbeginnt es mit dem Schreiben einiger Tests.   Ich\nführe einige Tests durch.  Wir sehen also, dass\ndie richtige Seite geöffnet wurde.  Es werden\nverschiedene Eingabefelder getestet, um zu prüfen, ob\ndie Suchleiste funktioniert.  Wir haben gesehen, dass Furby\nkorrekt gefunden wurde.  Simon wurde korrekt\ngefunden.  Und jetzt klickt es auf Knöpfe.\nAuch der Test des Kategoriefilters\nfunktioniert einwandfrei.  Meine Hände liegen wieder\nnicht auf der Tastatur.  Das ist alles\nSpielplan und Co-Pilot.  So super cool.\nUnd jetzt findet es alle\nSpielzeuge in dieser spezifischen Preisklasse korrekt.\nWenn ich also diese Funktionstests ausführe,\nkann ich aktiv nur sehen, dass der\nAgent diesen Code geschrieben hat, der Code\nwie erwartet funktioniert und die App\nwie erwartet funktioniert.  Es gibt also viele\nverschiedene Möglichkeiten, Ihre\nApp auf ihre Funktionalität zu testen, und alle unsere\nTests sind erfolgreich.  Sobald unsere Tests\nbestanden sind, würden wir\nin die nächste Phase übergehen und mit dem Schreiben\nunseres Refactorings beginnen.  Daher wird der vom\nAgenten erstellte Code so umstrukturiert, dass\ndiese Tests erfolgreich generiert werden.  Zum Schluss möchte\nich Ihnen noch einige bewährte\nVorgehensweisen im Zusammenhang mit\nBezahlung vorstellen.  Als Erstes möchte ich darauf hinweisen, dass\nPlayright bei der Ausführung dieser\nFunktionstests\nScreenshots von allen durchgeführten Tests erstellt\n.  Ich habe mir angewöhnt,\ndiese Bildschirmfotos zu einem Pull Request hinzuzufügen.\nWenn ich also Änderungen vorgenommen habe, werde ich\nsie einem Pull Request hinzufügen.  Die zweite Sache ist, dass\nSie es nicht dort ausführen müssen, wo es\nden Browser startet, wie Sie es im\nBeispiel gesehen haben.  Sie können es im Headless-\nModus ausführen.  Es läuft also im Hintergrund.  Und\nschließlich noch ein letzter Tipp: Committen Sie\nIhren Code, bevor Sie ihn tatsächlich zum Beheben\ndes Fehlers bringen, oder, wissen Sie,\nbevor Änderungen an Ihrem\nCode vorgenommen werden, denn wenn Sie nicht committen,\nerinnert sich das System möglicherweise nicht mehr an die vorherigen Änderungen\n.  Das wäre also eine Möglichkeit,\nund ich würde außerdem vorschlagen, für jedes\nFeature einen eigenen Test zu erstellen\n.  Zum Schluss noch einige\nRessourcen, die Sie sich ansehen könnten.  Ah,\nich habe vergessen, den Link zum GitHub-\nRepository hinzuzufügen.  Aber alle Folien werden\nunter diesem Link verfügbar sein\n.  Sie können sich die\nDokumentation ansehen und auch über\nsoziale Medien mit mir in Kontakt treten.  Ja, vielen\nDank an alle.  Ich glaube, das war meine gesamte\nZeit für heute.\nIch denke, wir haben zwei Minuten Zeit für\nFragen.  Hat jemand\nFragen\ndazu?  Ja, ich sehe da eine Frage.\nIch verwende\ndieses Beispiel.   Ja\n.\nWas sind Ihre Tipps für\nkomplexere Systeme,\nbei denen viel Zustandsverwaltung erforderlich ist?\nIch denke, wenn viel\nZustandsverwaltung nötig ist, würde\nich mich auf die Verwendung von Playright-Agenten konzentrieren, die\ndie spezifische\nAgent.mmd-Datei herunterladen, da diese\nspezielle Anweisungen enthält, die\nbesser für die Verwaltung von Zuständen und\nähnlichem geeignet sind.  Ich habe festgestellt, dass die Agenten von Playright,\ninsbesondere die Agenten von Playright,\nbereits viele gute Anleitungen integriert haben,\ndie dabei helfen sollten.  Eine weitere Möglichkeit wäre,\nwenn Sie nicht\nfür alles Playright verwenden möchten,\nIhre APIs auch direkt zu testen\n.  Falls eine API verfügbar ist, wäre das eine Möglichkeit\n.  Ähm,\nja, das würde ich empfehlen.   Gibt es sonst noch\nFragen?  Vielleicht\nnoch eine Frage.  Äh, wer, da bin\nich mir nicht sicher.  Ja.\nKann man auch in verschiedenen\nGrößen abspielen, zum Beispiel auf einem Desktop-PC?\nJa.   Ja\n.  Ja, das ist möglich.  Es kann die Ergebnisse auf dem\nMobilgerät mit denen auf dem Desktop vergleichen.  Es sollte einfach\nfunktionieren.  Ja.  Noch eine\nbrowserbasierte Überprüfung, um festzustellen, ob ich\neine Mac-App oder eine iPhone-App entwickle.  Es ist\nmomentan browserbasiert.  Ja,\nim Moment ist es nur browserbasiert.   Ja\n.\nOkay.  Ich glaube, das war alles, was\nich für heute Zeit habe.  Vielen Dank an\nalle.  Tut mir leid, dass kein Link zu\nGitHub vorhanden ist.",
  "transcript_chars": 18697,
  "ingested_at": "2026-05-16T22:30:37.588818+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 953,
    "like_count": 55,
    "channel_id": "UCLKPca3kwwd-B59HNr-_lvA",
    "categories": [
      "Science & Technology"
    ],
    "tags": [
      "ai",
      "ai engineer",
      "ai engineering",
      "software development",
      "tech",
      "startups",
      "software architecture",
      "machine learning"
    ]
  }
}