Transkript: PyTest

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast, Episode 53 mit PyTest.

Hi Jochen.

Ja, hallo, hallo, Dominik, willkommen.

Wir haben einen Gast dabei.

Und zwar den Florian.

Hey Florian.

Hallihallo.

Ja, haben wir zusammen.

Ja, wir haben gedacht, du machst doch öfter mal was mit PyTest und da haben wir gedacht, dann fragen wir sich doch einfach mal, ob du welche was darüber erzählen magst.

Genau.

Ich weiß nicht, vielleicht magst du ja einfach mal so ein bisschen erzählen, was du so tust oder irgendwie warum PyTest da ein ganz gutes Thema wäre.

Was ich so tue, ist schon eine Frage, da kann ich wahrscheinlich fünf Minuten dazu reden.

Ich mache tatsächlich so fast Vollzeit Open Source.

Und zwar kam das nicht von PyTest ursprünglich, sondern von einem anderen Projekt von mir, von Qt Browser.

Da kann ich euch weiter nochmal mehr dazu sagen.

Über das Projekt bin ich danach zu PyTest gekommen.

Und was ich jetzt eigentlich mache, ist zum einen, ich arbeite an Q-Browser und PyTests durch Spenden finanziert.

Und zum anderen gebe ich im Herbst jeweils hier an der Fachhochschule Python-Unterricht für Erstsemester Studierende.

Also Bachelor Informatik Studierende.

Also ja, ganz viel Open Source und ganz viel auch Freiheit, sag ich mal, wann ich was mache und eben nach viel PyTests.

Ja genau, du bist einer der Pytest Maintainer auch, ne?

Irgendwie da.

Genau.

Das hat auch ganz lustig schon angefangen.

Ich habe da halt eben durch Q Browser, durch dieses Projekt reingekommen, weil ich da Tests geschrieben hatte dafür.

Damals noch mit Unitest-Framework von Python, was mit Python mitkommt.

Und da gab es dann so ein Adopt PyTest Month, April 15, glaube ich, sowas.

Also doch schon eine Weile her, ja.

Wo dann Leute hinter Pytest, anderen Open Source Maintainern, anderen Projekten geholfen haben, nach PyTest umzusteigen.

Da habe ich eben mitgemacht mit Cube Browser und bin dann ziemlich schnell zu PyTest gekommen und habe angefangen, da Dinge zu verbessern, an Plugins, Dinge zu implementieren, die ich halt haben wollte oder die mir aufgefallen sind.

Und dann hieß es irgendwann, ja, willst du nicht das nächste Release machen?

Und ich fand halt, ja, Moment mal, ich habe ja noch nicht mal irgendwie Commit-Rechte.

Und wie es halt so läuft bei Open Source, seit da habe ich sie eben.

Cool.

Ja, sehe ich gut.

Über die ganze Sache müssen wir gleich nochmal besonders reden, auch über die Plugins und so, das klingt spannend.

Ich würde aber sagen, Jochen, wir fangen wie immer einmal mit den News an.

News, okay, alles klar.

Ja, ist auch ein bisschen was wieder zusammengekommen, weil jetzt die letzte Episode auch schon wieder ein bisschen was her ist.

Und genau, ja, was haben wir denn so?

Django 5.

Django 5 ist jetzt gerade letzte Woche rausgekommen.

Genau.

Das ist ja immer so, das kriege ich halt immer mit, weil ich muss halt immer alles umstellen.

Django im Einsatz.

Und ja, war aber diesmal sehr entspanntes Update, hat alles gut funktioniert.

Nicht wie deprecated.

Nee, also was die Verbesserung angeht, es ist auch, also es gibt ein tolles neues Ding, was halt irgendwie, ein Bug, der seit 18 Jahren offen war, ein Issue, der seit 18 Jahren offen, weil er jetzt geschlossen wurde, nämlich, da ging es darum, dass er eigentlich blöd ist, wenn man bei einem Model-Field irgendwie Default angibt, dass das halt nur dann ausgefüllt wird, wenn man irgendwie eine Zeile über, also das Modell tatsächlich über Django baut.

Und auch da ist es halt nicht immer so klar, dass das wirklich dann passiert, weil es gibt ja auch noch Bike-Create und man kann halt auf, man kann ja auf verschlungenen Wegen irgendwie Dinge erzeugen in der Datenbank.

Bile-Create macht Defaults nicht rein?

Nicht unbedingt.

Also es kann sein, dass wenn du das jetzt einfach so verwendest, dass es dann klappt.

Das war mir tatsächlich neu.

Aber wenn du das halt irgendwie so ein bisschen avancierter verwendest und wirklich schnell sein willst und dann kann es gut sein, dass das nicht passiert, weil, ja, und das ist natürlich doof.

Das hat wahrscheinlich auch mit der Funktionalität zu tun, dass man jetzt so Felder haben kann, die von anderen Feldern abhängig sind und zwar direkt im Feld, ohne das halt über die Safe-Methode zu machen.

Ja, nee, das weiß ich gar nicht, ob die direkt zusammenhängen.

Das geht jetzt auch, genau.

Die Sarah hat einen tollen Blogantrag zugeschrieben, vielleicht kennst du es nicht.

Gibt es auch ein Video, hat sie dazu gemacht.

Genau, die macht er hier auch die PyColon-Meetup-Gruppe organisiert mit.

Ja, genau, also was jetzt geht, ist halt, dass man nicht sagt Default in einem Model-Field, sondern DB underscore default.

Und dann wird das halt nicht nur gesetzt, wenn man halt irgendwie über Django das Ding baut, sondern halt in die Datenbank mit reingeschrieben, dass das so ist.

Und ja, das wäre schon mal ziemlich großartig.

Man kann es halt auch jetzt sehen, welche Defaults es gibt, wenn man einfach nur sich das Schema anguckt und nicht irgendwie den Applikationscode dazu hat, was ja auch so ein Ding ist, dass es halt blöd ist, wenn man ein Datenbankschema hat, dass man nur verstehen kann, wenn man einen Applikationscode auch dazu nickt, weil Applikationscode halt deutlich volatiler ist, oft als Datenbankschemata.

Ja, aber also das ist jetzt ziemlich cool und genau, so viele haben, also ich habe immer verwendet sowas wie Timestamp-Model aus den Django Extensions oder halt aus Django Model Utils, um zum Beispiel sowas wie Created Zeitstempel oder Modified Updated ranzubauen.

Das kann man ja jetzt halt auf eine deutlich elegantere Art machen.

Dann genau, diese.

Generated Field heißt das, glaube ich, ne?

Einfach Models Generated Field und dann.

Generated Field ist jetzt diese andere Geschichte, genau.

Genau, da kann man dann halt auch so Dinge, manchmal möchte man ja auch irgendwas indizieren können, was halt irgendwie.

Suche.

Ja, was halt auf irgendwas basiert, was halt berechnet wird aus unterschiedlichen Spalten, die man halt in einer Datenbank hat und nicht direkt irgendwie eine Spalte selber ist.

Und das geht jetzt halt auch relativ einfach.

Ja, dann gab es noch, ich habe jetzt aber ganz, ich habe jetzt ehrlich gesagt vergessen, was es genau war.

Es gab einige Verbesserungen an den Formularen.

Also man kann jetzt irgendwie Helptext und Label und Dinge irgendwie einfacher benutzen.

Wenn man jetzt einzelne Felder als Vielzeit einfach verwendet, dann sind die automatisch, glaube ich, mit dabei.

Genau, muss man vorher mal ganz umständlich auseinanderposteln.

Und ja, ehrlich gesagt, mehr kann ich mich nicht erinnern.

Aber ja, es ist auf jeden Fall eine coole neue Release.

Ja.

Du wolltest, wenn ich das richtig sehe, über diesen Open AI.

Ich weiß nicht genau, ob euch das irgendwie tangiert oder ob ihr da was davon mitbekommen habt, ob man da davon, ob ich das nur mitbekommen habe, weil ich das halt zufällig irgendwie alle immer verfolge.

Ja, erzähl doch erstmal von was du da genau erzählen möchtest.

Naja, es gab ja da so leichte irgendwie Schwankungen im Open AI Management.

Management, ja.

Ich bin hier, ich bin doch nicht hier, ich bin wieder da, Hura.

Genau.

Und ja, was da so der, was da so der Hintergrund ist, ich weiß es nicht, vielleicht ist es auch etwas, wo man eigentlich gar nichts zu sagen sollte, weil es einfach, es hat halt einen bestimmten Unterhaltungswert und das kann man.

Ja, dann lass uns doch ein bisschen leichte Unterhaltung vorweg machen, weil man hört ja so ein paar Gerüchte.

Ja, was hast du denn gehört?

Ja, ich erzähl mal, ich bin erstmal gespannt.

Also man hört ja immer.

Ich habe ganz viel gehört, ich weiß es aber nicht.

Also ich würde denken, dass die, ja, dass der Hauptgrund halt irgendwie darin besteht, dass es halt diese komische Konstruktion gibt, dass OpenAI ja eigentlich eine Non-Profit-Organisation ist und die kontrolliert halt die kommerzielle Entität, die halt nur deswegen gegründet worden ist, weil man halt diese Chat-GPT-Geschichte auch als Produkt irgendwie rausbringen wollte und man gesagt hat, okay, das können wir nicht im Rahmen von diesem Non-Profit machen, weil das wird einfach zu teuer.

Und wir müssen da irgendwie auch Fremdkapital haben, um das halt irgendwie alles brechnen zu können und so.

Und ja, im Vorfeld davon ist jetzt, der Name fällt mir nicht mehr ein, der Gründer von Anthropic, also der Firma, die jetzt auch Claude irgendwie gebaut hat.

Das ist also ein quasi ein ähnliches Ding ist wie ChatGPG bloß halt sozusagen von der anderen Firma.

Der war vorher bei OpenAI und der hat auch schon mal versucht, Sam Oldman vom Board feuern zu lassen.

Also der hat zuerst gesagt, so, hey, das ist nicht okay, so geht das nicht.

Und wenn das, das könnt ihr ja so nicht machen.

Und dann hieß es so, ach doch, geht doch.

Und dann hat er sich ans Board gewinnt und gesagt, feuert den, feuert den CEO mal, das ist irgendwie nicht okay.

Und dann hat das Board drüber nachgedacht und gesagt, nee.

Und dann hat er gesagt, gut, dann gehe ich jetzt halt.

Und hat ein paar Leute mitgenommen und dann halt eine neue Firma aufgemacht.

Und ja, aber das ist jetzt noch gar nicht so lange her.

Also ich meine, da überschlagen sich natürlich so ein bisschen die Ereignisse irgendwie, aber das ist jetzt auch erst knapp über ein Jahr her.

Und ja, offenbar.

Seitdem ist der Rest, die neuen Sachen sind alle ziemlich closed, wenn man so ein bisschen genauer hinguckt.

Ja, das ist natürlich immer so ein bisschen, also OpenAI, ne?

Ich meine, der Name ist so ein bisschen.

Ja, und natürlich ist halt auch die Frage.

Die PayPal sind geschlossen, da sind nur noch Zusammenfassungen drin und keine richtig guten Erkenntnisse mehr und so.

Ja, ja, das sind nur noch so Technical Reports.

Und natürlich, also OpenAI macht keine Open Source Modelle oder sowas.

Die haben überhaupt nie irgendwas released.

Und eigentlich ist ja die Mission von dem Non-Profit sozusagen der Allgemeinheit irgendwie zu nutzen.

Ja, wäre ja mal schon.

Und dann ist halt die Frage, die Frage, wie lässt sich das vereinbaren, wenn man auf der einen Seite halt irgendwie jede Menge Risikokapital nimmt und irgendwie dann Produkte baut und dann Geld dafür einnimmt und sich im Grunde in Konkurrenz zieht mit den großen Tech-Giganten und halt auch ja von einem von denen halt ja massiv finanziert wird, ne, irgendwie, ich weiß nicht, Microsoft hat halt irgendwie eine Milliarde reingesteckt oder so und halt auch eine Bewertung hat inzwischen von, weiß ich nicht, 80 Milliarden oder irgendwie ganz unglaubliche Beträge.

Ja, dann und dann halt auch nichts mehr in der Richtung tut, was halt die Mission eigentlich vorgibt, dann kann ich mir schon vorstellen, dass das Spannung macht und dass die Leute dann halt auch irgendwann sagen, so jetzt reicht's aber.

Also das, was ich so unter der Handhöre ist natürlich Bulted, wissen wir alle, aber Q-Star haben sie gefragt und hat gesagt, vorher ihn schmeißen wir raus.

Bitte?

Sie haben Q-Star gefragt.

Q-Star hat gesagt.

Q-Star, das ist.

Das ist die nächste Vision.

Achso.

Ja, das kann man natürlich.

Ja, ich weiß auch nicht.

Also, ja, dann gab es ja auch diese ganzen komischen Lobby-Aktivitäten, irgendwie jetzt auch was AI-Ackt in Europa angeht und so, wo man ja auch sagen muss, mhm.

Wir sind für eine AI-Regulierung, sagte der Minister.

Ich meine, Regulierung ist ja vielleicht gar nicht so schlecht, aber sozusagen die Konkurrenz von OpenAI zu regulieren, sodass man die Regulierung um Erlaubnis fragen muss, bevor man da irgendwas machen darf, ist vielleicht, also ich bin, ich bin, ich bin, also das ist ganz neu fasst.

Fasst will man vielleicht nicht aufmachen, aber dass man, dass man das regulieren will, dass Leute da nicht zu Schaden kommen, das kann ich durchaus nachvollziehen.

Ja und nein.

Ja, also ich finde, aber das ist ja, da kann man wenig gegen sagen.

Also man sagt.

Nein, der Wunsch ist richtig, würde ich sagen.

Ja.

Aber dass man jetzt die Technik selber reguliert, das finde ich halt komisch.

Weil das ist halt irgendwie, und ja, da gab es halt diverse Lobby-Schrecken.

Die Frage ist halt, wie das halt überhaupt geht, ohne dass man jetzt den Stecker zieht oder so.

Naja, jedenfalls ist es ja jetzt auch nicht so gekommen.

Es ist jetzt die Richtlinie, oder das ist ja noch nicht unter Dach und Fach, es ist halt bloß irgendwie sozusagen, es gibt ein Verhaltensergebnis, auch irgendwie seit letzter Woche oder sowas.

Das sagt ja auch im Grunde, ja, im Wesentlichen, wir regulieren halt die Anwendung, aber nicht die Technik selber.

Ja, also Transparenz regeln wir halt ganz gut, ne nach dem Motto, du musst das Modell halt irgendwie verändern.

Ja, Open Source ist halt explizit ausgenommen.

Das ist halt schon mal großartig.

Was halt bedeutet, okay, wenn ich jetzt hingehen will und sage, okay, ich mache hier meine eigene Suchmaschine oder so auf internen Dokumenten, die halt irgendwie besser funktionieren soll, dann muss ich nicht OpenAI fragen, sondern dann kann ich das halt irgendwie selber machen.

Kann ich mir ein Lammer feintunen oder was auch, mit einem Mistral oder was auch immer.

Und kann das halt einfach machen.

Und es ist nicht verboten, einfach so.

Ja.

Also, genau, also schon mal.

Also im Grunde ist eigentlich alles halbwegs okay.

Und Sam Ortman ist ja auch wieder zurück zu OpenAI, ist ja auch wieder alles okay.

Und ich glaube, das mit dem Nutzen für die Gesellschaft, das kriegen sie bestimmt auch noch hin.

Ich glaube nicht, dass ihnen da das Geld zu Kopf steigt oder da irgendwie irgendwas dran machen kann, wenn da jemand eine Milliarde innimmt.

Das ist, glaube ich, kein Problem für den.

Nein, niemals.

Warum sollte denn niemals irgendwie sich jemand korrumpieren lassen?

Ja, also, nee, nee.

Ja.

Und ich meine, das Board hat ja schon gezeigt, dass sie da irgendwie absolut in der Lage sind, auch das zu kontrollieren und durchzusetzen, wenn sie finden, dass das nicht okay ist.

Daher, ich habe da überhaupt gar keine Bedingungen.

Ja, okay.

Also das war sozusagen die leichte Unterhaltung.

Ja, das war die leichte Unterhaltung zum Thema kurz vor Weihnachten nochmal ein bisschen Advent.

Ja.

Advent of Code und Rust kann man auch wieder spielen.

Ja, genau, was hatten wir noch so?

News.

Du hast noch eine wichtige News.

Naja, wichtig.

Für Python Removal.

Genau, Gill Removal ist beschlossene Sache.

Wer sich dafür interessiert, es gibt da einen schönen, es gibt einen neuen Podcast.

Ich weiß auch nicht, ob wir den schon erwähnt hatten.

Core PY heißt er, ist irgendwie von Lukas Langer und Pablo Galindo Salgado, irgendwie den Release-Managern für die letzten Python-Versionen, die machen den und reden halt über so Seapython-interner Geschichten.

Zum Beispiel war das die erste Episode über den Seapython-Core Dev-Sprint oder halt andere Themen, wie zum Beispiel jetzt, dass es dann Justin Time-Compiler irgendwie für 3.13 wohl geben soll und solche Dinge.

Und das da gab es jetzt auch eine Episode über das Entfernen von Gill, was halt eine komplizierte Geschichte ist und viel Arbeit wird, aber ja, jetzt wird das Ganze wohl angegangen und bin gespannt.

Ich fand halt die Tagline ganz lustig vom Podcast.

One talks like a Mexican, the other like a Russian.

Both hate the comparison.

Weil das ist Cinder X, das ist die letzte Folge.

Die letzte habe ich, glaube ich, noch nicht gehört, ja.

Da haben sie, ah, da haben sie mit Karl Meyer geredet?

Karl Meyer, ganz interessanter Typ von der Frage.

Von Meta?

Ja, genau, der hat ja Meta, aber der ist einer der Hauptentwickler hinter dem Django Python-Kern von Instagram.

Und der hat, da gab es mal eine sehr interessante Episode, ich habe jetzt wieder vergessen, wo und wann, aber worüber geredet hat, was man so Probleme kriegt, wenn man halt irgendwie mehr als, deutlich mehr als eine Million Zeilen Python irgendwie hat, die und da eine Anwendung, die darauf basiert, dass man.

Ich glaube, den Artikel hatten wir auch schon das eine oder andere Mal irgendwo in den Show Nutz gelingt, wenn ich mich recht erzinze.

Kann sein, ja.

Also genau, das kann man, also ja, ich habe so nicht.

Guter Podcast.

Ja, genau, und dann erinnere ich mich noch, letztes Jahr hatten wir darüber geredet, dass es da so gewisse Sicherheitsschwankungen bei LastPass gab.

Ja.

Und da dachte ich, okay, muss ich diesmal auch.

Ich kann mich an den Januar und Ende Februar erinnern, wo ich tausend Passwörter herumstellen musste.

War super.

Wo ich dann gesagt habe, ja, ist okay, so prinzipiell ist OnePasswort jetzt auch nicht so viel besser, zum Beispiel.

Aber zum Glück sind sie noch nicht irgendwie hops genommen worden.

Ja, das hat sich jetzt geändert.

Ist auch One-Passwort hops genommen worden.

Und zwar über Okta.

Also ich denke so, okay, Okta ist auch so ein.

Also ich verstehe nicht genau, warum Unternehmen sowas verwenden, aber okay.

Ja, ist ja total super.

SSO und so muss man alles über so einen Anbieter machen.

Ist Okta nicht auch hinter Zero Ours?

Ja, auch Zero, ja.

Ja, der dünn.

Ja, also ich glaube, es war nicht so ganz super schlimm, aber dazu gab es auch ein Postmortem, was wir veröffentlicht haben und das war einfach nur, wenn man sich das anguckt, das war einfach nur total schrecklich.

Also peinlich.

Oh ja, wir versprechen euch, es ist gar nicht geleakt worden und ist auch nichts kaputt gegangen.

Es sind jetzt so ein paar Dokumente verloren gegangen.

Ja, aber ja, also.

Zugriff auf die Datenbank oder sowas.

Ja, ich habe auch keine gute Lösung dafür.

Ich weiß nicht, wenn es das, also das, ja.

Ich finde es schwierig tatsächlich.

Wir hatten ja letztes Jahr schon mal ein Jahr das Thema.

Ja, das Thema hatten wir schon mal, es kommt irgendwie immer wieder.

Verrätst du, wie du das machst, Florian?

Passwörter?

Ja, tatsächlich ganz langweilig lokal bisher.

Mit KeyPass XC ist es, glaube ich, inzwischen.

Ich bin da mal irgendwie gewechselt von einem Volk zum anderen.

Das und dann so ein minimales Frontend darüber namens Keep Menü, was dann auf Rofi aufsetzt.

Also so ein Keyboard-Menü.

Und dann ja, wenn ich mal irgendwie was brauche, was editieren muss oder so, mache ich halt dieses KeyPass XC auf und sonst einfach alles mit Tastaturkürzel und Autotype.

Aber du kommst halt auch von dem Rechner nicht runter, ne?

Und wenn der Rechner irgendwie dein Backup ein Problem hat, dann ist blöd.

Das ist so, ja.

Ich habe tatsächlich dann teilweise das Problem, dass ich halt irgendwo am Handy mal irgendwo ein Passwort brauche oder so.

Aber ich bin eh so der Mensch, der fast immer seinen Laptop dabei hat.

Zum einen, und was Backups angeht, habe ich das tatsächlich dann alles mal ausgedrückt und in ein Bankschließfach gelesen.

Ja, das glaube ich auch.

Das ist keine so schlechte Idee.

Weil ich halt doch fand, ja, wenn das weg ist, habe ich echt ein gröbeles Problem.

Ja, also ich finde auch für mich allein oder so, da bin ich auch Keeper, das war, das klingt, das sah schon gut aus, aber das Problem für mich ist halt auch der Support von irgendwie so Familie und Verwandten und das und Sharing und mal irgendwie für jemanden was falsch halten und so.

Und das, da habe ich bisher noch keine gute Geschichte gefunden.

Ja, ich finde also 2FA tatsächlich gar nicht so schlecht.

Dann und dann halt immer irgendwie so ein Key mitnehmen, wo ich halt auch, dann geht es halt nur zweimal oder sowas und einer ist dann halt im Bankschließwach.

Und den brauchst du halt dann.

Und so.

Das ist auch keine schlechte Idee, finde ich.

Ja, also.

Was ich mir wahrscheinlich anschauen würde, wenn ich jetzt was will, was ein bisschen mehr Clouds dran hat, sag ich mal.

Spitwarden.

Weil das ist, glaube ich, größtenteils Open Source und es gibt, glaube ich, auch eine alternative Server-Implementation, die man dann irgendwie selber hosten kann.

Ja, also ich habe es mir angeguckt, ich wollte auch erst als Umstände, ich habe damit angefangen und ich weiß nicht.

Also ich bin so ein Usability, ich möchte das immer einfach und schnell und so haben und irgendwie nervt es mich.

Ganz sei, dass das technisch die sauberste Lösung ist, aber ich fand es irgendwie total anstrengend.

Ja.

Naja.

Ja, okay.

Also vielleicht müssen wir einfach nächstes Jahr nochmal drüber hin und kommen zu tun.

Ja, vielleicht ist ja irgendwas.

Also mir fällt aber auch nichts ein, was man irgendwie so architektonisch hat.

Man muss irgendeinen Tod muss man immer sterben.

Also zum Beispiel, wir, wie teile ich auch, ne, jetzt so hatten wir auch letztes Mal, glaube ich, irgendwie Geheimnisse durch Entwicklungsteams irgendwie, ne?

Auch nicht so einfach.

Ja.

Also ich benutze jetzt tatsächlich so einen Service, wo halt die Entwickler gar nicht mehr die Geheimnisse kennen müssen, der halt autogeneriert werden, das heißt, ich kenne die selber nicht, aber man muss sich halt mit der API dahin verbinden und dieser Service kennt die halt alle.

Also, ne?

Es ist halt auch dann wieder irgendeine Party, die da halt einen Halbzugriff drauf hat, aber gut, dass da jetzt nichts kritisch ist und so.

Und ja, gut.

Aber immerhin läuft der Rest dann so.

Naja.

Das ist schwierig.

Okay, ja, ich weiß nicht.

Ansonsten habe ich jetzt keine News mehr, glaube ich.

Vielleicht bräuchte man einfach ordentliche Tests für diese wundervollen Passwort-Manager.

Tja.

Ja, die Überleitung war jetzt ein bisschen hakelig gleich, aber vielleicht reden wir über das Thema, dann haben wir heute noch News fertig.

Ja, genau.

Und dann können wir eigentlich mal hier Pytest starten.

Ja, ich glaube, die meisten Menschen wissen, was Pytest ist, also das Test-Framework, was man oft benutzt, wenn man Tests in Python schreiben möchte.

Würde ich auch empfehlen, ehrlicherweise.

Ihr wahrscheinlich auch.

Alleinig.

Keine Überraschung soweit.

Aber dann überlasst wir einfach mal dem Florian vielleicht das Wort und den Einstieg in das Thema vielleicht auch.

Das erzählt sie ja vielleicht auch öfter.

Also ich fand auf jeden Fall den Vortrag, den auf der Last-View Python darüber gehalten hat, schon ziemlich gut.

Der war spannend und ja.

Erzähle ich tatsächlich öfter, weil ich ja auch Firmenkurse mache zu PyTests.

Das wären so die Einzelfirmmaschine, die ich eben neben den Open Source-Dingen noch fahre.

Und da mache ich halt auch erstmal ein bisschen Werbung für PyTests.

Gerade früher war das vielleicht noch ein bisschen wichtiger, weil da gab es oft echt noch Firmen, die umgestiegen sind von Unitest oder von Nose.

Ein anderes Test-Framework.

Inzwischen muss man sagen, dass weg so das Default eigentlich PyTest ist.

Also Nose-Test ist sogar deprecated, oder?

Nose, ja, ja.

Nee, nee.

Nose-Tests gibt es nicht.

Ja, Nose-Tests.

Habe ich falsch verstanden.

Da stand schon seit Jahren in der Dokumentation, man soll bitte kein Nose verwenden.

Es gibt irgendwie ein Nose 2, aber ich habe noch kein Projekt gefunden, was das nutzt, so effektiv.

Und wenn man sich halt dann so anschaut, wie die Userzahlen so ausschauen, es gibt jeweils jährlich so eine Umfrage, die Python Developer Survey von der Python Software Foundation und ChatBrains.

Und da hat PyTest, ich glaube, vorletztes Jahr oder so die 50% Marke geknackt.

Okay.

Ich hätte sogar mehr gemacht.

Warum möglicherweise?

Ja, wobei ich irgendwie 30% halt sagen, sie nutzen gar kein Test-Framework.

Okay.

Also würdet ihr den Test benutzen oder wann würdet ihr den Test benutzen?

Das ist vielleicht auch eine spannende Frage.

Oder wofür alles?

100% Coverage.

Jeder Commit, der die Coverage reduziert, wird automatisch nicht durch den Commit durchgelassen oder gibt es da unterschiedliche Ansichten?

Ich habe tatsächlich ein Projekt jetzt, wo ich das versuche.

Für das Modul, was ich eben an der Fachhochschule unterrichte, da habe ich pro Jahr irgendwo 100 Studierende und das Modul heißt Automatisierung mit Python.

Und ich habe dann eben halt auch meine Arbeit hinter dem Modul so ein bisschen automatisiert, zumindest so der langweilige Teil.

Also irgendwie Noten dann ausrechnen und E-Mails verschicken mit der Notenaufschlüsselung und sowas.

Und da bin ich jetzt dran, das alles ein bisschen zu refacturen und für den neuen Teil quasi, was refactured ist, auch wirklich 100% Test Coverage zu haben.

Weil ich halt finde, ja, ich berechne da irgendwie Zeugnis-Noten und so, das muss halt schon irgendwie keine Box haben, idealerweise.

Also ich finde auch, also kritische Teile der Infrastruktur sind ganz gut, wenn man sie testet.

Also sowas wie Authentifizierung, Autorisierung oder sowas, sollte man schon irgendwo mal gucken, dass das stimmt.

So die kritische Business-Logik.

Also jede Einzelner-Funktion weiß ich jetzt nicht.

Ja, es gibt ja Leute, die diesen Standpunkt vertreten und sagen, naja gut, wenn man, wenn man anfängt, über solche Zahlen zu diskutieren, dann machen das eigentlich nur 100% Sinn.

Aber ich weiß auch nicht, ob das jetzt optimal ist für alle.

Also ich habe auch, ich hab, ich hab's für einen Projekt gemacht, weil einfach ich das mal machen wollte.

Ob das jetzt nötig wäre, weiß ich nicht.

Und es wird schon anstrengend.

Also gerade wenn man dann externe Komponenten drin hat, die irgendwie eine GUI-Applikation schreibt oder so, dann wird es schon schwierig irgendwann.

Ja genau, also welche Enden muss ich man danach testen.

Also ich finde ja da tatsächlich auch, vielleicht jetzt direkt an dem Zeitpunkt TDD ganz interessant.

Also dass man mit den Tests anfängt, die zu schreiben.

Es ist nicht immer ganz einfach, weil man muss halt schon relativ genau wissen, was man machen will.

Und wenn man das nicht weiß, dann baut man halt Tests, die man hinterher wieder wegschmeißen kann, was die doppelte und dreifache Arbeit macht.

Aber wenn man halt irgendwie schon ein gutes Konzept hat, dann erst Tests dafür zu schreiben, wie das aussehen sollte und dann die Implementierung, das führt halt dazu, dass die dann auch tatsächlich funktioniert, ja.

Wenn man sich so Gedanken dazu gemacht hat, wo so die Haken und Stellen sind, die ineinandergreifen sollen.

Ja.

Macht ihr das auch mal manchmal?

Ich mache es ganz gerne bei Box, wenn ich halt irgendwo einen Bugreport kriege, dass ich erstmal einen Test dafür schreibe.

Zumindest so ab dem Punkt, wo ich das einmal manuell reproduziert habe.

Weil wenn ich den Bug fixe, werde ich das eh schon ein paar Mal reproduzieren müssen und dann mache ich mir halt effektiv das Leben leichter.

Also ich würde auch sagen, das fix ist immer ein Test.

Genau.

So bei einer Library kann ich es mir auch noch vorstellen.

Und wenn es dann eher Richtung Applikation geht, finde ich, wird es schon schwieriger.

Also gerade jetzt wieder bei einer GUI-Applikation, da muss ich das Feature irgendwie erstmal implementieren und erstmal sehen, wie das aussieht aus User-Sicht, aus Code-Sicht auch, bevor ich da irgendwie sinnvoll Tests dafür schreiben kann, finde ich.

Klingt sehr vernünftig, würde ich, würde ich, würde ich ganz, würde ich ganz genauso sehen.

Also ich mache auch TDD manchmal, aber gerade so bei Web-Applikationen.

Wirklich, also oft ist es ja so, man fängt mit irgendwas an oder mir geht das halt so und dann denkt man sich irgendwann, ah nee, das ist einfach keine gute Idee.

Und ich mache das auch oft in Notebooks am Anfang.

Einfach nur, um zu sehen, ob irgendwas geht oder elegant geht und wenn es dann nicht geht, dann sage ich so, okay, pff, ne, dann mach ich doch lieber was anderes.

Und wenn man dazu erst die Tests schreibt, dann schmeißt man die Tests ja mit weg.

Das macht ja irgendwie, ich hab dann, ich hab dann mal, es gab auf Twitter irgendwie einen Thread, wo dann, weiß ich nicht, Harry Percival, der auch dieses, dieses Obey the Testing Go, dem Testbuch geschrieben hat für Python, irgendwie meinte, dass Leute doch bitte mal TDD verwenden sollen und sich mal einen Brief leisten sollen, dann möchte ich so, ich mach das mal so.

Ich weiß nicht, ich habe so das Gefühl, wenn ich zuerst Test schreiben würde, das wäre totale Verschwendung, weil wenn ich schmeiß dann oft Sachen wieder weg.

Warum sollte ich da Tests für Sachen schreiben nicht wieder weg?

Nee, nee, das ist ein Spike, das ist auch TDD, das ist schon okay.

Okay, na gut.

Ja, aber ja, also oft muss man erstmal sehen, ob irgendwas so funktioniert, wie man denkt und dann.

Und wenn man zum Beispiel die Modelle jetzt noch nicht hat von so einem Problem, ne?

Oder die erstmal definieren muss.

Also manchmal muss man ja irgendwie Ficture schreiben, dann erstmal, um zu gucken, was denn überhaupt an Datenmodellen, wie die aussehen sollen

und so.

Oft lasse ich die Modelle weg und schreibe gar keine Modelle, sondern ich schreibe erstmal so, um zu sehen, ob das in der UI funktioniert.

Das wäre dann ein Integration-Test?

Nö, ich schreibe da gar kein, wie gesagt, an der Stelle kann man noch nicht so Text schreiben.

Also wenn ich mit Tests anfangen würde, würde ich ja mit den Tests vielleicht fürs Modell anfangen oder so, aber wenn ich kein Modell habe, ist es halt ein bisschen.

Ja, okay.

Ich will noch kurz nochmal beim Testing-Gode anknüpfen.

Da hat jemand letztens ganz einen lustigen Thread aufgemacht, wo er fand, ja, er hat mal Chat-GPT gefragt, wo das PyTest-Logo herkommt.

Und ChatGPT meinte dann, ja, ich hätte das designt.

Ist Quatsch.

Ist völlig Quatsch.

Das Logo gibt es nämlich schon irgendwie seit 2014 und ich bin erst ein Jahr später zu PyTest dazugekommen.

Ja, GPT lügt bei Python regelmäßig.

Es denkt zum Beispiel auch, dass irgendwelche anderen Menschen den Python-Podcast machen würden, die ich dort nicht gehört habe.

Aber hey.

Ja, ich habe dann aber tatsächlich mal rumgegraben in den Mailinglists-Archiven und rausgefunden, warum das so eine Panflöte ist.

Ach, okay, das ist interessant.

Die sollen nämlich tatsächlich an diesem Testing-Gode als Maskottchen auf diesem Buch anknüpfen.

Weil Paarnflöten eben genutzt wurden, wohl um Ziegen zu herden.

Wir sagt man in Deutsch.

Äh, Züten.

Züten, ja, ja.

Hm.

Ja.

Ja, ich fand das mit dem ChatGPD dann ganz witzig.

Ich habe dann auch nochmal so ein bisschen nachgehakt und finde so, nö, das war nicht ich.

Und dann meint sie, ja, nee, es tut mir leid, es war Armin Rollacher.

Ach so.

Und da fand ich halt auch, äh, nö.

Und dann meint er irgendwas von einem Daniel Urstöger, auch bekannt als Blue-Logo, habe ich gesucht, nichts gefunden zu der Person und fand immer noch, nee, kann nicht sein.

Und dann fand er immer noch, ja, tut mir wirklich leid und so.

Es war von Daniel Hahler gemacht, was halt auch nicht stimmt.

Mir, ich habe gerade auch nochmal gefragt und mir sagt es, dass es nicht genau weiß, weil es von einem Community-Wettbewerb stammen würde.

Ja, dann hast du wahrscheinlich dieses GPT-4-Modell.

Das 2.5.

Okay, interessant.

Ja, also das ist halt wirklich, weil er sich irgendwie manchmal auch sehr fantasiert halt.

Sicheres Auftreten bei vollkommener Ahnungslosigkeit.

Was fällt dir dazu ein?

Das mir auf jeden Fall die Punktführte besser gefällt als ein Schäferhund als Logo für Py-Test.

Ja, die Punktführte ist super.

Ja, was, was haben wir denn, was haben wir denn so an Dingen, die man da, über die man mal.

Ja, das würde mich auch mal interessieren, genau.

Du machst viele Pythest-Schulungen.

Geht das überhaupt?

Also ich habe irgendwie so ein bisschen, ich mache, ich mache auch manchmal Schulungen, auch so Python-Einführungen oder halt auch mal zu speziellen Themen und habe immer so das Gefühl, ich weiß nicht so genau, ob ich, ob das, wie man am besten Wert irgendwie schafft für die Leute, die daran teilnehmen, weil ich habe manchmal so das Gefühl, die sind dann halt dann zwei Tage oder drei Tage da und dann machen sie das dann aber doch wieder so, wie sie das kennen, irgendwie, wenn sie wieder da weg sind.

Und gerade bei so Test-Driven Development ist es halt, habe ich das Gefühl, oder überhaupt beim Testen, so ein Ding, wo sich das erst so über die Zeit irgendwie einstellt, wo man das schlecht irgendwie so einmal in, so musst du das halt machen und dann, sondern es ist mehr so ein Ding, so ein.

Wegschmeißen nochmal machen, wegschmeißen nochmal machen.

Ja, aber man muss sich halt da so ein bisschen dran gewöhnen und das muss halt über eine längere Zeit irgendwie passieren und ich habe da noch nicht so einen Dreh gefunden, wie man das am besten vermitteln kann.

Ja, ich sag, an sich sage ich das den Leuten schon auch so.

Es ist auch irgendwie viel Erfahrung dahinter, die kann ich euch nicht abnehmen.

Aber ich kann euch halt erstmal die Werkzeuge in die Hand geben und euch einfach mal zeigen, was kann man an sich vielleicht eher ein bisschen abstrakter mit Pythes überhaupt machen.

Was sind so die Möglichkeiten?

Wie man die dann anwendet auf die konkrete Fälle, die die Leute da haben, steht dann teilweise schon nochmal ein bisschen auf einem anderen Blatt.

Aber ich finde es schon ganz nützlich, dass die Leute halt sehen, was gibt es denn überhaupt.

Ja.

Da habe ich vielleicht noch eine kurze Geschichte auch, wie das mit diesen Trainings angefangen hat.

Das war nämlich auch ganz witzig.

Das war, als ich PyTest erst ein paar Monate gebraucht habe, auch noch irgendwie im 2015.

Und zwar zur Europyton da in Bilbao, aus Spanien.

Da wurde ich von Holger Krekel, also nicht ich, aber Holger Krekel, also so der Vater von PyTest, der hat halt auf der Mailingliste gefragt, ob jemand dieses Training übernehmen kann an der EuroPython, weil er war irgendwie verhindert, kurzfristig.

Und es hat sich dann niemand gemeldet.

Und ich fand halt so, ja, hm, das ist irgendwie ein Material da, Spanien klingt auch irgendwie toll.

Ich war noch nie auf irgendwie einer Python-Konferenz.

Ja, machen wir.

Dann im gleichen Jahr noch auch das erste Firmentraining dann von ihm übernommen, weil er eh langsam aufgehört hat mit Py-Tests und zu anderen Projekten übergegangen ist.

Und seit da dann basierend auf seinen Materialien das halt immer weiterentwickelt.

Das klingt aber gut.

Das klingt gut.

Ja, also da sind viele interessante Sachen und ich würde auch die einzelnen auch nochmal vielleicht kurz anschneiden, dass man so ein bisschen darüber erklärt.

Für die Menschen, die das noch nicht so kennen.

Wollen wir uns da eine Struktur geben, wie wir anfangen, weil sie nicht nochmal reden, wie man vielleicht Pictures am besten macht oder was das überhaupt ist oder ob man die braucht oder wie man die baut oder und dann irgendwann vielleicht über diese ganzen Plugins oder so ein paar extra Sachen geht.

Es gibt ja wunderschöne Sachen, die, also die ich auch am Anfang nicht kannte.

Das letzte, was ich, wo ich mich erst mich so ein bisschen gesträubt hatte, war irgendwie Hypothesis.

Das habe ich dann durch deine Veranstaltung lieber Florian nochmal dann eingebaut und war überrascht, dass ich, also was heißt überrascht, aber ich habe noch so ein paar Bugs angefressen.

Oh, die habe ich jetzt noch nicht gesehen.

Und ja, da kommt man so ein bisschen auch an die Grenzen dessen, was Python so kann.

Und ja, ich weiß nicht, wo würdest du denn anfangen bei PyTest?

Ich würde glaube ich jetzt tatsächlich nicht generell über PyTest, aber ich würde nochmal kurz gerne bei Coverage einhaucken, weil wir das Thema schon gehabt haben und vielleicht nicht alle wissen, was das eigentlich ist.

Da frage ich jeweils auch so rum bei den Firmenkursen und oft so viele Leute fanden, ja, nee, das machen sie eigentlich nicht, dass sie irgendwie Coverage messen.

Da geht es darum, dass man sich ganz einfach anschaut, welche Zeilen von meinem Code wurden von meinen Tests ausgeführt.

Was einem dann einen Eindruck zumindest geben kann, was ist getestet oder was wird zumindest ausgeführt von den Tests, muss nicht zwingend dann heißen, dass die Tests auch gut sind oder wirklich was testen, aber es wird zumindest mal ausgeführt.

Ja, der blöd ist halt dann, wenn über 100% Coverage, also der ganze Code ist durchgelaufen, aber es ist trotzdem irgendwas kaputt.

Kann einem halt auch passieren, ja.

Auch schwierig, da Prozent Coverage gerade in einem Team, sich irgendwie auf Ziel zu setzen, weil dann wird es bestimmt Leute geben, die dann einfach diese Zahl hochtreiben, ohne wirklich noch gute Tests zu schreiben.

Ja, ja, genau, weil ja, das würde ich auch sagen.

Also wenn man es halt nur macht, um irgendwie, ne, irgendeinen Ast nochmal zu durchzuwandern, ohne dass es halt irgendwas bringt, ist halt blöd.

Aber gibt es ja sowas, wo ihr sagen würdet, so aus euren Eigenprojekten so Pi mal Daumen, so eine Coverage ist okay.

Nee, ich würde nicht, also meistens, wenn ich nicht drauf achte, lande ich irgendwo so bei irgendwie ein bisschen über 80% oder sowas.

Aber 80% wäre jetzt auch so meine erste Reaktion gewesen.

Also ich würde sagen, wenn man schon zwei Tests schreibt oder so, die so ein bisschen das machen, was man, testen, was man macht, dann sind ja schon mal über 60, 70 meistens drüber.

Das weiß ich nicht, aber.

Ja, je nachdem wie groß das Projekt ist natürlich.

Also klar, am Anfang hast du einfach viel mehr Gewinn.

Also so ein paar Tests, die halt, wenn bei der Web-Applikation jetzt die Views einfach nur durchgehen und gucken, ob man okay zurückkommt irgendwie in den Standardfällen, da hast du halt sehr wenig Tests geschrieben und viel Gewinn quasi, weil wenn das kaputt geht.

Und das wird dann halt immer weniger irgendwann.

Und irgendwann, dass er natürlich ein Punkt erreicht, wo es halt eigentlich keinen Sinn mehr macht und man aufhören kann.

Aber wann der erreicht ist, keine Ahnung.

Schwer zu sagen.

Also ja.

Tja.

Ja, am Schluss muss man sich danach einfach mal so die Daten dahinter anschauen und mal schauen, was habe ich denn noch nicht getestet.

Ja, da kann es eben sein, es wurde einfach vergessen.

Es ist irgendwie eine Fehler-Condition, die es vielleicht ganz gut ist, die zu testen.

Oder es kann halt sein, dass es eben Code, der nicht einfach testbar ist und dann muss man sich überlegen, ist da von Wert.

Es gibt halt so zwei, ich würde sagen, Dinge, die es ein bisschen schwierig machen.

Und zwar klar, also man kann jetzt natürlich sehr viel einfacher Tests schreiben, wenn man ganz klar weiß, wie jetzt von einer kleinen Funktion, von irgendeiner Closure, irgendwie der Contract ist halt.

Also wenn man weiß, was reingeht, was rausgehen muss.

Was halt auch bedeutet, dass man dazu tendiert, die relativ statisch zum Beispiel zu typisieren oder zumindest die Type-Annotations dann nochmal abzufangen oder irgendwie sowas.

Naja gut, das macht ja jetzt wenig Sinn, würde ich sagen, wenn du die Type-Annotations dann nochmal testest, ist es irgendwie.

Ja, nein, aber du tust halt, dass das, was reinkommt, dann auch dem entspricht vielleicht.

Oder dass man halt das eng.

Das bedeutet aber halt, dass man auch die Dynamik verliert oder die Flexibilität.

Auch jetzt irgendwie, wenn man jetzt API schreibt und dann irgendwie die Daten validieren möchte, klar kann man jetzt ganz streng sein und jedes Mal dann, wenn es nicht passt, einfach zurückgeben, okay, danke, du darfst nicht

oder so.

Ich glaube, ich glaube, das läuft jetzt quasi darauf hinaus, wie sollte so eine Test, es gibt ja diese Testpyramide, wie sollte die aussehen?

Quasi, ja.

Weil sozusagen, also ja, dass man halt viele Unit-Tests hat, irgendwie dann weniger irgendwie Tests, die halt irgendwie größere Sachen testen und dann halt nur ganz weniger irgendwie so End-to-End-Tests oder so.

Genau, man kann sich natürlich jetzt sicher auch mit sowas wie Playwright oder sowas eine komplette Frontend-Integrationsstrecke bauen, die jedes Mal dann testet, ob die Farbe bei dem Button sich geändert hat und zwei Zentimeter links oder rechts sind, aber wenn halt irgendwie eine Ruffolge im Designer kommt, dann die ganzen Pipelines jetzt mal auseinanderfliegen, ist wahrscheinlich eher zu viel.

Genau.

So, aber also ich glaube, man muss halt irgendwie so sich überlegen, was der Anwendungsfall, ob der sinnvoll ist, halt auch.

Also ob es halt einen Sinn hat, dass man eine breite Anwendungsfall hat oder ob man das so enger scopen möchte.

Und das würdet ihr wahrscheinlich am besten wissen, wenn ihr Anwendungen baut, an welchen Stellen die nicht auseinanderfliegen sollte.

Also wenn ihr irgendwas macht, was wichtig ist, irgendwie wo Leben dran hängen oder was teuer ist oder sowas, dann sollte man da vielleicht ein bisschen mehr Hirnschmeiß reinstecken, das so ein bisschen sauberer zu programmieren.

Und ich habe immer das Gefühl, also Tests haben mir auch sehr geholfen, so die Architektur, mit der ich irgendwie überhaupt Programme schreibe, so ein bisschen zu überdenken, weil man halt merkt, dass man halt, also so große Module oder sowas oder Dinge, die viel machen, dass die schwierig halt werden, also da zu testen.

Aber es vielleicht auch eine doofe Idee ist, wenn in einer Methode oder in einer Funktion super viele Sachen gleichzeitig passieren.

Und solche Dinge.

Und ja.

Und da kommen wir halt auch wieder zu Coverage, ne?

Wenn man halt so viel Zeugs hat, was passiert, auf einmal passiert, also ein bisschen sich so von diesem einen Ding für eine Sache Prinzip verabschiedet, dann wird das halt auch relativ schwierig zu testen dann, ja.

Oder überhaupt dann so hinzukommen, dass die Sachen so passieren oder dass man die Bugs dann findet.

Ja, aber ich fürchte, man kann nicht einfach sagen, man muss das halt so machen und dann ist es halt, weil das sind so widerstreitende Dinge und so Trade-offs.

Also ich würde ja auch zuständigen, genau, das ist halt, also das ist auch etwas, was beim Testen, was ich gut finde, dass man halt irgendwie so ein bisschen in die Richtung gedrängt wird, sich darüber Gedanken zu machen, wie man Sachen halt so hinschreibt, dass man sie gut testen kann.

Und irgendwann hat man das dann halt auch so ein bisschen verinnerlicht, dass man weiß man schon, wie man am besten Dinge so hinschreibt, dass die Tests sehr einfach hinzuschreiben sind.

Und wenn das nicht geht, dann ist das halt auch einfach nichts, was man halt so schreiben sollte wahrscheinlich.

Auf der anderen Seite, also es ist halt auch so, wäre es halt schön oder elegant von der Architektur her, wenn man jetzt halt eher schmale und tiefe Funktionen hat.

Ja, also sozusagen, aber die sind halt schwer zu testen, auch unter Umständen.

Also es ist nicht unbedingt, also du kannst natürlich auch viele Funktionen, also dass es etwas super zu testen ist, muss jetzt nicht unbedingt bedeuten, dass es halt auch total elegant ist, zum Beispiel zu verwenden.

Also es kann sein, dass zum Beispiel, nehmen wir mal an, ein Beispiel für eine sehr schlechte API, die ganze Java-File-Igwie Buffered-Reader, irgendwas, sonst was API.

Also ich könnte mir vorstellen, dass das relativ einfach zu testen ist, aber es ist halt ein Alptrom, das zu benutzen.

Und die, nehmen wir an, ja, Unix-File-API oder halt auch irgendwie, keine Ahnung, Requests-API in Python, die ist halt schön, weil die ist halt schmal und tief.

Aber ich könnte mir vorstellen, dass Requests zu testen eventuell ziemlicher Schmerz ist.

Es hängt halt davon ab, was dein Anwendungsfall ist, ob das jetzt, also wenn du sagst jetzt irgendwie, das ist eine interne Funktion und da ist es schön, wenn man die einfach testen kann, dann macht es halt Sinn, das vielleicht so zu machen.

Aber wenn das jetzt was ist, was nach außen geht, wo User dann halt den Schmerz haben, dass du es einfach zu testen hast und zu sagen, naja, nee, dann muss es halt für User einfach zu verwenden sein.

Und wenn das halt bedeutet, dass es schmerzhaft ist, das zu testen, dann ist es halt so, weil wichtiger ist an der Stelle die User Experience.

Also es hängt halt davon, es kommt halt drauf an, denke ich.

Jo.

Ja, um auch vielleicht nochmal bei dieser Testing-Pyramid einzuhängen, ich finde da immer so, ich finde das ein bisschen zu kurz gedacht.

Also es kommt halt immer sehr darauf an, was man testet.

Und man soll sich halt zu den Vor- und Nachteilen von diesen Größen, sag ich mal, von Tests bewusst sein.

Aber ich finde jetzt nicht, man kann immer sagen, dass die eine Art ist besser als die andere Art.

Ja.

Wenn ich jetzt ein Command-Line-Tool teste, bietet sich es vielleicht an, da eher N-to-N-Tests zu schreiben, weil ich dann wirklich auch den Output und so testen kann.

Und eher sparsam so wie für einzelne Funktionen Unitests zu schreiben.

Oder auch, ich bin viel auch jetzt bei Firmen für die Kurse, die eigentlich gar keinen Python-Code mit Py-Test testen.

Das fand ich auch ganz spannend.

Das ist auch total interessant.

Sondern die beispielsweise Waschmaschinen mit PyTest testen.

Also da halt eine Waschmaschine haben, wo deren Firmware drauf läuft und die wollen sie halt testen.

Und wollen halt dazu PyTests nutzen, weil es eben zusammen mit Python ein relativ einfaches und flexibles Werkzeug darstellt.

Gucken, ob noch alles geht.

Wenn man die richtigen Höfe drückt und das richtige Programm läuft.

Ja, und die Tests sind halt einfach zu schreiben.

Ja, das ist eine gute Idee.

Oder bei einem Kunden von mir, um vielleicht dann gleich die Überleitung zu den Fixtures zu machen an der Stelle, die nutzen eine Py-Test-Fixture, um eine Klimakammer anzusteuern.

Dann so eine Klimakammer mit Elektronik drin und sagen dann halt über eine Py-Test-Fixture heiz mir das jetzt auf auf 30 Grad und dann lasse ich da meine System-Tests für dieses Gerät laufen.

Oha.

Wo auch wieder halt alles andere als Python-Code getestet wird.

Ja, spannend, wenn man halt wirklich das mit in die Realität überträgt und quasi auch seine Hardware damit steuert, um die Testumgebung außerhalb des Rechners aufzubauen oder halt aufzuheizen.

Bestimmen die Parameter, machen die das, was sie sollen.

Das ist, ja.

Jetzt habe ich das vergessen, was ich eigentlich sagen wollte.

Überleben zu Fixtures.

Das auch, aber vorher noch, was eigentlich mein Punkt war, da hat man ja dann gar keine Wahl, welche Größen von Tests man schreiben will.

Also da schreibt man fast gezwungenermaßen dann eben System-Tests oder so End-to-End-Tests.

Man kann ja nicht mehr wirklich einzelne Funktionen dieses Geräts, also jetzt im Sinne eines Unit-Tests, testen.

Ja, im Grunde ist das ja auch schon so, wenn man, wenn man Pytests zum Schreiben von End-to-Entests, was man ja auch machen kann, verwendet, wie zum Beispiel PyTest Playwright oder so, dann da ist ja auch eigentlich jeder Test im Grunde, man muss halt den Browser aufmachen, dann da wohin und dann.

Ja, von daher finde ich so dieses Testing-Pyramid, ich meine, die Idee ist ja auch steinalt, muss man dazu sagen.

Bin ich mit Vorsicht zu genießen.

Dann aber vielleicht tatsächlich dazu zu Fictions und was Fictures sind und wie man die baut oder macht ihr das mit Factories oder macht ihr das ohne Factories oder sind Factories doof?

Oder du gibt es ja so verschiedene Sachen und was sind überhaupt Fictures und ja, also vielleicht so fertige Dinge, die so tun, als wären sie etwas, was das Programm normalerweise kann.

Das war jetzt ein bisschen abstrakt.

Ich gebe da ein einfaches Beispiel.

Also wenn wir mit einem normalen Webclient zum Beispiel arbeiten würden, dann wird halt eine Ficture der User und einem Client und dann guckt man, wie das interagiert.

Ja, am Schluss ist eine Fixture im Prinzip einfach eine Funktion, die halt aus PyTest Fixture markiert ist oder dekoriert ist.

Und diese Fixture kann entweder irgendwelche Setup-Schritte vornehmen für einen Test und oder irgendwelche Objekte für den Test bereitstellen.

Das heißt, das kann jetzt sein, wenn ich irgendwo eine Config-Klasse habe, vielleicht in meinem Code, dann habe ich vielleicht in meinen Tests eben eine config-fixture, was mir eine sinnvoll konfigurierte Instanz gibt von dieser Conf-Klasse.

Oder in den Trainings habe ich das Beispiel von so einem RPN-Kalculator, den ich testen will, der nimmt dann auch eine Config als Argument und sowas.

Und damit ich einfach nur die Instanzierung von diesem RPN-Kalculator, also einfach einen Taschenrechner im Prinzip in Python geschrieben, damit ich das nicht copy-pasten muss in jedem Test, mache ich mir eben so eine Fixture-Funktion, wo ich das alles aufsetze, zurückgebe und Tests können dann diese Fixture eben nutzen.

Mit dem Ziel, eben so diese Setup-Schritte schön zu isolieren aus den Testfunktionen.

Also man baut sich quasi das Objekt, das die API bereitstellt, einmal irgendwie mit den Parametern nach, wie man sie ihnen echt auch gerne hätte, um die dann in dem Test benutzen zu können, zu gucken, ob die Ergebnisse, die man erwartet, dementsprechen, was man möchte.

Genau.

Ist ja schwierig, das jetzt so ein paar Sätze zu fassen.

Ja, ich finde das auch sehr abstrakt halt.

Also wenn man das nicht gut sieht, dann wird das relativ klar.

Die Spezialität bei Pytest-Fixtures ist halt, dass sie so, dass es da diese magische Dependency-Injection gibt, sodass man halt einfach nur den Namen der Fixture in die Parameter im Test schreibt und dann das automatisch ausgefällt.

Genau, dafür schreibt man die Funktion ja quasi in den Conf-Test einfach rein.

Ja, nö, musste nicht.

Ja, aber auch das ist schon, ja genau, aber auch gute Frage, ist das eine gute Idee und so?

Hängt davon ab.

Aber es ist halt, also ich weiß auch nicht, ob man das heute nochmal machen würde, wenn man das nochmal designt, weil das ist schon sehr magisch.

Und ich meine, ansonsten hat man ja, wenn man jetzt eine Funktion einfach aufrufen würde oder so, haben wir ja auch Support in der IDE, dass man draufklicken kann und landet dann da.

Das ist ja jetzt, also bei PyCharm geht das zum Beispiel, dass man halt auf einfach auf eine Fixture in Pythagoras klickt und dann halt bei dem richtigen Code landet.

Aber das ist halt natürlich irgendwie nur dadurch, dass da jemand die Arbeit investiert hat, irgendwie das parsen zu können und so.

Also das wird wahrscheinlich nicht überall funktionieren.

Es gibt auch eine Extension für andere Editoren einer Wei.

Ja, es ist schon eigenartig, ja.

Also ich sage so, das inzwischen habe ich es, glaube ich, raus, wie ich das den Leuten erkläre, dass das passt.

Aber gerade so am Anfang mit den Trainings war das so der Punkt, wo ich sagen musste, ja, ich war doch jetzt erstmal verwirren und irgendwann werde ich es verstehen, aber wenn ich nicht gerade vom ersten Satz.

Ja, ich fand das auch sehr, sehr schwierig.

Also vor allen Dingen diesen Unterschied zwischen Modul-Scope, Class-Based Scope und Function-Based Scope-Fixtures und sowas.

Und erstmal zu verstehen, dass halt eine Fixture irgendwie eigentlich ein Generator ist, der irgendwie halt das Setup und Tierdown vor und nachher macht und eigentlich nicht was returns, sondern eher was yieldet und dann, was da so passiert, das war schwer zu verstehen.

Also auch diese, dass die Fixtures alle immer neu gebaut werden, dann für jeden Test, Atomat und so, das war alles so ein bisschen, ja, das hat ein bisschen gebraucht, würde ich sagen.

Gut, das sind jetzt ja alles Dinge mit diesem Caching-Scope und Yield und Teerdown und so, das kommt ja dann erstmal obendrauf auf das Grundkonzept.

Ja, ja.

Also um Fixtures an sich erstmal zu verstehen, kann man das, glaube ich, das meiste davon weglassen.

Ja, ich glaube, meistens fällt man halt irgendwie direkt rüber und die machen halt dann irgendwelche Dinge, die man nicht erwartet und da kann man sich also schon ein bisschen mit in den Fuß schießen.

Also ich würde auch empfehlen, also nicht am Anfang zu viele komplexe Tests da zu schreiben, nur vielleicht erstmal einen kleinen oder ein, zwei kleine und halt einfache Objekte einzugeben, wo man halt guckt, wie die zusammenhängen zum Beispiel oder was die tun.

Also was ich halt hinterher wirklich schwierig finde, ist dann Objekte zu erzeugen oder viele Objekte oder halt dann, man kann, was halt auch sehr schön ist, was Florin auch gut gezeigt hat, ist irgendwie Parametrisierung mit beispielsweise Data-Clusters oder sowas, dass man halt tatsächlich eine Plethera hundert verschiedene Dinge erstellt, automatisiert erzeugt an Tests, die die verschiedenen Edge Cases seiner Fälle dann halt auch beinhalten und man halt dann die Logik testen kann, ob sie da halt da noch reicht.

Ohne jetzt direkt auf Hypothesis zu gehen, halt Hypothesis testet nochmal, also mit zufälligen Fixtures, wenn ich das richtig verstehe, ja.

Oder Zufallswerten für Dinge in den Fictures.

Ja, vielleicht noch kurz zur Parametrisierung.

Wenn ich mir jetzt PyTests anschauen würde und mal so die erste Testfunktion geschrieben habe, wäre das sicherlich so eines der ersten Dinge, das ich anschauen würde.

Ist auch eines der ersten Dinge dann in meinem Training.

Weil das, finde ich, es halt echt einfach macht, ziemlich viel abzudecken.

Wenn man jetzt irgendeine Funktion testet, um halt eben nicht einen Input und einen Output nur zu testen.

Jetzt mal bei irgendeiner langweiligen Utility-Funktion.

Ich habe bei mir zum Beispiel so ein Format Seconds, wo ich einfach Sekunden übergebe und das dann schön formatiere in halt Stunden, Minuten, Sekunden beispielsweise.

Oh, das ist eine Seite übrigens, kurzer Exkurs, äh, F-String irgendwie Docs, kann das sein?

F-String.help, genau.

Oh ja,

die habe ich auch schon oft.

Ja, eine Webseite von mir.

Habe ich mal irgendwann eine PyCon Germany, ich wollte es schon seit Jahren machen und dann kamen da die Lightning Talks unter PyCon Germany und am Abend vor den Lightning Talks habe ich die noch kurz gemacht, um sie dann eben da vorstellen zu können.

Ja, aber die ist echt super, weil sowas hat echt gefehlt, inzwischen möchte ich da reingucken.

Das ist echt gut.

Hör ich gerne.

Ja, Parameterization.

Macht es einem eben einfach, um dann aus einer Testfunktion, die nur einen Wert testet, den so zu erweitern, um zum Beispiel 10 oder 20 Werte zu testen, ohne 10 oder 20 separate Funktionen dafür schreiben zu müssen.

Und das ist sowas, das vermisse ich dann sehr schnell in anderen Test-Frameworks.

Meistens geht das schon irgendwie, aber halt mit einer aufwendigeren Syntax als in Python oder als mit PyTest.

Ja, genau, also PyTest Parameterze ist halt irgendwie dann der Dekorator, den man da verwendet.

Den benutze ich auch ständig.

Aber es gibt auch noch die andere Möglichkeit, man kann auch irgendwie Fixtures, die können irgendwie mehrere Dinge zurückgeben und dann werden auch, wird das, werden die auch quasi sozusagen wie unterschiedliche Parameter, also wird der Test auch mehrfach ausgeführt mit den Unterricht.

Du meinst, wenn du mehrfach hintereinander yieldest, weil das beim ersten Aufbruch, beim zweiten Aufbruch oder

dritten Abruf ist?

Nee, nee, nee.

Ich weiß es gar nicht mehr genau.

Nee, du kannst im Fixture Decorator kannst du halt nochmal eine Liste von Params annehmen.

Genau.

Und dann wird jeder Test, der die Fixture nutzt, wird halt mehrmals ausgeführt.

Ja.

Genau, genau.

Mit der Idee, wenn du irgendwie mehrere Backends hast oder mehrere Implementationen, die sich aber eigentlich gleich verhalten sollen, dass du dann halt eine ganze Batterie von Tests über beide beispielsweise laufen lassen kannst.

Ja.

Genau, mir war das nur in Erinnerung geblieben, als das ist auch eine Art, wie man Parametrisierung machen könnte, aber tatsächlich sehe ich eigentlich auch immer eher nur Python's Parametrize und den anderen Weg eigentlich.

Genau, du kannst gerade beide Sachen gehen, entweder direkt an den Test anschreiben oder halt an die Fixche.

Genau, aber es ist sicherlich ein bisschen exotischer.

Ja, das ist halt ganz nützlich, ne?

Gerade für das Tee da.

Und also die Frage ist halt, nutzt ihr irgendwie sowas wie Factories oder sowas?

Also, dass man dann Objekte zusammenbaut, ja, man könnte ja eine Factory schreiben, um einen User zu erzeugen, was da alles rein muss, der dann zum Beispiel Defaults enthält.

Da habe ich einen schönen Blog-Eintrag zu gesehen, wie man das ordentlich machen soll.

Irgendwie, ja, weil es gab zwischendurch mal so eine Bibliothek, die hieß Factory Boy, die habe ich dann irgendwann wieder rausgeschmissen, die dann solche Sachen machte, aber nicht so, wie das, wie ich das schön fand.

Also mittlerweile glaube ich, man nimmt halt irgendwie dann Einzeldinge von Faker vielleicht, um sich Zufallssachen auch erstellen zu lassen.

Ja, denke ich, ist aber ein anderes Problem.

Also ja.

Und dann baut halt dann diese Funktion halt dann zufällig Objekte zusammen und dann könnte man ja zum Beispiel sagen, parametrisiere das mal für, keine Ahnung, 10 oder 20 zufällige Nutzer aus so einer Factory heraus und benutze die halt einfach mal.

Was die Tests natürlich nicht ganz so reproduzierbar macht vielleicht, aber vielleicht dann halt auch doch.

Je nachdem, wie man das halt festgelegt hat.

Das wäre halt dann interessant, wie oft man das laufen lässt, um zu gucken, ist das Ergebnis immer gleich?

Hat man einen Spezialverwusst nicht passt?

Hat man Fehler in der Factory gebaut?

Nimmt man vielleicht sogar die Factory später auch für den eigentlichen Programmcode, um dann wirklich was Neues zu erzeugen?

Ja, ich weiß jetzt nicht, wie sinnvoll ich das halte.

Also so gezielt sowas zu nutzen, wie jetzt auch Hypothesis, was wir sicherlich noch darauf sprechen.

Also Jochen wird es zerstören.

Ja, ich hab sowas, Factory Boy, sowas früher mal verwendet, aber ich mach das eigentlich inzwischen nicht mehr.

Mach noch kurz fertig.

Ja, ja, also ich hab, also einfach deswegen, weil ich finde, das macht einfach zu viel Magie mit irgendwelchen, du hast ja dann auch wieder so Dekoratoren für die Paar.

Also, und ich weiß gar nicht, ob man, ob diese Magie so viel bringt.

Also, das ist immer so, das Verhältnis von wie viel Magie ist da und wie schwer ist das zu verstehen, im Verhältnis zu wie viel Nutzen bringt, das ist für mich jetzt inzwischen nicht mehr so, also diese Relation ist nicht so, dass ich sagen würde, das ist total sinnvoll, das zu verwenden, sondern ich denke mir eher so, inzwischen ist halt auch irgendwie, wenn man halt ordentliche Funktionen, die solche Daten generieren, schreibt, halt auch mit entsprechend benannten, weiß ich nicht, Keyword-only-Argumenten oder so, dann ist das eigentlich immer die bessere Variante.

Und ich habe auch oft jetzt in Projekten inzwischen sowas wie so ein Dev-Data-Modul oder so, wo ich mir halt Daten für bestimmte, und das brauche ich halt nicht nur für Tests, sondern halt auch einfach, um Applikationen gezielt in bestimmte Zustände versetzen zu können, um halt zum Beispiel irgendwas zeigen zu können oder so, dass ich halt mir für diese Fälle, die ich dann habe, halt immer irgendwie sowas schreibe, wo ich dann einfach nur eine Funktion aufrufe, wo ich sagen kann, okay, versetz meinen Applikationszustand mal in diese, also meine Applikation mal in diesen Zustand, damit ich irgendwas demonstrieren kann.

Und das kann ich dann halt auch für Tests verwenden.

Das heißt, sozusagen dieses Generieren von diesen Daten oder so ist schon in meiner Applikation drin und das benutze ich dann in den Tests halt auch.

Und ich benutze eigentlich sowas wie Factory Boy und sowas gar nicht mehr.

Ich habe gerade den Blogartikel gefunden, den ich meinte.

Zu den von Look Plant.

Look Plant, genau.

Ja, okay.

Ja, der ist gut.

Ja, und so ähnlich habe ich das auch dann, glaube ich, versucht umzubauen.

Genau, weil der macht dann quasi ja auch so ein.

Das ist ja halt quasi das, was ich meinte, ne?

Default-Keyword-Arguments mit vielleicht einem Faker dazu.

Und dann hast du halt eine parametrisierbare Art.

Ja, und Faker ist halt nochmal eine andere Geschichte, wo es einfach darum geht, dass man halt, wenn man jetzt, dass man sich nicht alles selber ausdenken muss, dass es plausible Daten hat.

Okay, ja, das macht dann Sinn.

Dann kann man das Fackel auch den Seed mitgeben zum Beispiel, ja.

Und dann kannst du halt.

Dann ist es immer gleich.

Ja.

Ja, vielleicht wäre das jetzt gerade der Punkt, um noch was zur Hypothesis

zu sagen.

Ja, klingt gut.

Das ist ein Projekt, was erstmal nicht viel mit PyTest zu tun hat, aber sich halt doch gut im PyTest integriert.

Zu sogenannten Property-Based Testing.

Man kann sich das so ein bisschen wie ein Futter vorstellen, was also Zufallsdaten generiert.

Ja, man kann mir zum Beispiel sagen, gib mir irgendeinen Integer, ne?

Und dann nimmt er alle, die er finden kann.

Ja, jetzt nicht alle.

Ich glaube, standardmäßig führt es dann halt 200 Mal oder so die Testfunktion aus.

Also nicht so viel.

Und alle Integer wird eh schwierig.

Also Herbert kann auch sehr langsam werden, wenn man das machen.

Aber halt mit der Idee, dass man sich eben so Strategien zusammenbauen kann.

Also auch sagen kann, ich will jetzt gerne irgendwie Dictionaries und die Keys sollen Strings sein, aber nur mit ASCII-Zeichen.

Und die Values sollen dann irgendwie Listen sein und die Elemente darin sollen dann irgendwie das und das sein.

Oder auch passend beispielsweise auch auf ein Django Model und sowas.

Und dann kann man sich mit diesen Strategien halt ein bisschen gezielter Daten generieren und dann halt eben auf seine Funktionen loslassen.

Und gerade bei so bestimmten Arten von Code, gerade wenn es darum geht, irgendwo Dinge aus einem String zu parsen oder so, ist das relativ einfach, sich da so eine Strategie auszudenken oder auch einfach zu sagen, schmeiß da bitte mal Zufallsdaten hin.

Einfach zufällige Strings.

Und dann, wenn es geht, noch irgendwelche Invariance zu testen.

Also Dinge, die immer wahr sein sollen, egal was der Input ist.

Also wenn man irgendwas ein Compressed und ein Decompressed hat, dann kann man das einmal durchlassen, einmal sagen, Compress, einmal Decompress, dann soll das gleiche wieder rauskommen.

Und decrypt, Encrypt, Encode, Decode, alles so diese Paare, die sich halt umkehren sollten.

Ja, dann merkt man relativ schnell, ob man irgendein Kaiser hat, wo, ups.

Genau, und dann lasst man das mal laufen und dann ist die Chance relativ groß, dass Hypothesis halt mit irgendeinem komischen Corona-Case kommt, den man echt nicht bedacht hatte.

Ja, das ist mir auch schon etwas auf die Füße gefallen, hat mir dann die Augen geöffnet, warum mir zwischendurch irgendwas komisches passierte, was man irgendwie nicht erwartet hätte, ja.

Da muss man nochmal drüber nachdenken, was mache ich denn da überhaupt eigentlich?

Wenn was kaputt ist, das schon immer so ein bisschen.

Ja, ich glaube, das muss ich mir mal, ich hab das, ich hab das schon mal ausprobiert, aber ich hab's noch nicht wirklich häufig irgendwie in den Dingen so verwendet, die ich so mache.

Also ich hatte das Gefühl, tatsächlich, dass es so ein bisschen langsam ist, aber dann kann man das ja auch, glaube ich, aufzeichnen, glaube ich.

Ja, die Idee davon ist eigentlich, dass es eben nicht langsam ist.

Dass man es halt als Teil seiner normalen Tests laufen lassen kann.

Aber also für mich war das immer so ein Punkt, wo ich dann angefangen habe, tatsächlich die Sachen einzuschränken.

Also wenn ich halt gemerkt habe, okay, es ist langsam halt eine Unit dann laufen lassen mit maximal möglichen Parametern.

Und dann war es halt natürlich langsam, hat der Test dann vielleicht auch mal fast eine Minute gedauert oder so.

Aber dann habe ich halt tatsächlich Extracades gefunden, die ich rausschmeißen konnte und konnte dann mir sinnvoll überlegen, okay, der Eingabe wäre jetzt vielleicht doch nur maximal, weiß ich nicht, siebenstellig oder so.

Und nicht noch mehr.

Und dann wurde dann der Test natürlich dann viel schneller.

Und dann habe ich halt gesagt, sorry, aber mehr ist jetzt hier einfach nicht erlaubt.

Und das halt direkt mit abgefangen.

Und so, das war, glaube ich, an der Stelle eine gute Strategie, um halt so ein bisschen so die Grenzen zu gucken, was überhaupt an I.O.

da sinnvoll ist auch.

Oder so eine Sanitization zu machen an Teil-Schellen oder sowas Gutes.

Ja, und am Schluss muss halt auch der Code, der dann irgendwas testet, genug schnell sein, dass man den 200 Mal laufen lassen kann und es dann halt trotzdem nur idealerweise in Bruchteil in einer Sekunde geht.

Das ist nicht immer der Fall.

Ja.

Ja, das ist auch so ein interessantes Thema, finde ich.

Also ich mag das sehr gerne, wenn es halbwegs schnell durchlaufen.

Ich finde das aber sehr frustrierend, wenn Projekte so, wenn die Tests so ewig brauchen, weil das halt auch macht das Entwickeln irgendwie echt langsam.

Ja, also idealerweise halt so ein, zwei Sekunden nebenbei in der Idee, dann kann man sie dann parallel laufen lassen und sieht direkt, wenn man irgendwas kaputt gemacht hat.

Ja.

Das ist auch gut.

Ja, es geht halt nicht.

Das war schön, aber ist dann bei größeren Projekten.

Das ist schwierig, ja.

Ist irgendwann nicht mehr realistisch.

Aber wenn eben auch so End-to-End-Tests dabei sind.

Dafür gibt es ja Testmarker.

Man könnte jetzt hingehen, könnte alle Tests, die nicht so schnell gehen, als langsam markieren oder sowas und die halt nicht immer parallel laufen lassen, sondern nur dann, wenn man es explizit möchte oder in der Pipeline oder so.

Und nur die Schnellen standardmäßig nebenbei von der IDE prüfen lassen.

Ja, kommt halt auch ein bisschen drauf an, wie viele Tests man da hat.

Ja.

Also wenn ich mir jetzt Py-Tests selbst anschaue, wenn ich mir Q-Browser anschaue, dann ist das irgendwas Vierstelliges.

Und dann wird es zeitlich halt einfach knapp, auch wenn die Tests selbst relativ schnell sind.

Ist jetzt bei Q-Browser nicht der Fall, da sind relativ viele End-to-end-Tests und halt GUI-Applikationen und so.

Aber selbst wenn die Tests schnell sind, wenn es halt ein paar Tausende sind sogar in einem größeren Projekt, dann ist das Endergebnis halt nicht mehr so schnell.

Naja, irgendwann kann man halt nichts mehr machen.

Was vielleicht noch ganz.

Was man ja eventuell machen könnte, aber die meisten, meistens, das hat man ja vielleicht auch nicht immer, was testet dann letztlich, gut, ich meine, ich bin jetzt da eher im Web-Anwendungsumfeld unterwegs, was da die Tests langsam macht, ist halt immer, wenn man irgendwie Datenbankzugriffe macht oder so und Tests, dann ist halt das immer langsam.

Jetzt könnte man natürlich, das weiß ich nicht, ich habe das ehrlich gesagt noch nie, ich habe es einmal selber gemacht, auch um es auszuprobieren.

Was man da ja tun könnte, ist halt so Repository-Padtern oder so verwenden und dann halt quasi die Datenbank wegabstrahieren und dann für die Tests halt durch irgendwie eine Dummy-Datenbank ersetzen, die halt dann schnell ist und dann sind die nicht mehr langsam.

Hast du schon mal gesehen, dass das jemand erfolgreich gemacht hat und dass es im größeren Projekt dann wirklich gut funktioniert hat?

Weil, ja, das könnte ja ein Weg sein.

Ja, ich bin jetzt nicht so viel im Web-Unfeld unterwegs.

Ich habe ein Projekt, was ich maintaine, Studentenportal.

So ein Portal für Lernhilfen und Zitate von Dozierenden und sowas.

Halt von Studierenden für Studierende.

Und das ist eine Django-Applikation und da hatten wir das mal diskutiert und sind dann zum Schluss gekommen, dass wir einfach zu viele datenbankspezifische Kleinigkeiten haben.

Also spätestens wo du halt irgendeine Volltext-Suche verwendest und das halt dann so PostgreSQL Fulltext-Search nutzt, dann kannst du das nicht mal so auf die Schnelle ersetzen.

Oder wenn du es kannst, läufst du also in die Gefahr, dass die Tests dann überhaupt nicht mehr das testen, was eigentlich in der Realität läuft.

Ja, klar.

Das ist natürlich das Problem dabei.

Ja.

Ich finde es auch schwierig.

Also so Datenbanksachen testen, muss man sich oft darauf verlassen, dass das irgendwie geht.

Und dass das jemand andere Menschen schon getestet haben.

Und ja, das fällt dann halt auch tatsächlich oft runter, weil das so ein bisschen nervig sein kann.

Also, weil das halt so langsam wird dann im Entwickeln und wenn man das alles aufsetzen muss, dann muss ja auch die Datenbank laufen.

Also ganz ehrlich, also alleine eine Datenbank laufen zu lassen auf einem Dev-Rechner ist manchmal schon eine Herausforderung, je nachdem, was man alles drauf haben muss.

Gut, man muss ja auch eine Webseite angucken können auf ein Dev-System.

Das Darken auch schon für.

Ja, aber wenn dann halt Menschen drei oder vier oder fünf verschiedene Projekte gleichzeitig machen lassen, dann haben die nur irgendwie einen Rechner mit 8g Gramm oder sowas, muss dann irgendwie da mal einen Docker drauf haben und dann müssen die Container aber irgendwie alle gleichzeitig anleihen, weil die schnell wechseln müssen.

Dann macht es dann bei fünf verschiedenen Datenbanken schon bumm.

Dann musst du dann irgendwie gucken, dass du vielleicht eine hast, die dann irgendwie wegkaufst ist, wo dann aber auch die Klienten stimmen.

Und dann musst du, wenn eine abreißt, nicht alle abreißen, weil den Container nicht einfach kaputt machen kannst, die wollen das nichts lassen.

Und ja, rennen wir schnell schon wieder mit dem Kopf gegen irgendeine Wand.

Da wäre es so eine

Softwareentwicklung mit 8 Gigabyte RAM, finde ich halt auch so ein bisschen kritisch.

Ja, ist eine Katastrophe, ist das.

Also Gott sei Dank muss ich sowas nicht tun.

Also Apple macht das ja, dass sie ihre neuen MacBook Pros haben im Standardmodell mit 8 Gigabyte für tausend noch was Euro.

Ja, das ist eine Gemeinheit, aber ja, so ist es.

Aber ja, ich meine, ich mit Cute Browser, vielleicht soll ich da ja dann auch mal noch ein paar Worte dazu sagen.

Da muss ich halt ab und zu nach Chromium kompilieren, also der Code hinter Google Chrome.

Und das braucht so mit einem Developer-Bild, also mit Debug-Symbolen und so, braucht das halt mal so irgendwie um die 30 Gigabyte RAM.

Wow, allein das Kompilieren von dem.

Okay, das.

Allein das Kompilieren.

Wenn ich es halt parallel machen würde, nur mit so einem Bildjob würde es wahrscheinlich, würde auch weniger reichen.

Aber ja, wir haben dann 32 GB tatsächlich nicht mehr ausgereicht.

Ich bin jetzt auf 48, was halt das Maximale ist, was in einem Laptop passt überhaupt.

Weil 16, glaube ich, fix eingelötet sind.

Aber das fand ich schon heftig.

Also Chromium ist ein riesiges Projekt.

Aber wenn es so weitergeht, das wird dann nur noch komplexer, wie es bei Software halt oft so ist.

Habe ich echt irgendwann ein Problem.

Habt ihr schon mal Tests irgendwo auf anderen Rechnern laufen lassen, einfach nur?

Also habe ich auch schon mal gehört, dass Leute das gar nicht bei sich mehr laufen lassen, sondern irgendwo nur in der Pipeline.

Mache ich ganz oft auf Weil halt.

Also bei mir gehen die Tests dann halt auch eine Weile und oft lasse ich die dann lokal halt gar nicht mehr laufen.

Das ist eine gefährliche Angewohnheit.

Sondern ich pushe das halt mal, wenn ich noch vernünftig bin in einem Branch und nicht gleich nach Main.

Und schaue dann halt mal, was da zurückkommt von GitHub Actions.

Dieser Test ist viel geschlagen.

Oh, ja, okay.

Meistens nicht.

Manchmal gelingt es einem halt, das durchzukriegen, aber ja.

Ja, okay.

Muss das aber halt ja.

Was auch super ist, wenn man dann gar keine Testung gegen hat, sondern dass halt

direkt durchgeht.

Da hast du halt noch keine Entwicklungsumgebung.

Das ist da Code Spaces oder so und dann ist das alles nur noch.

Na Cloud.

Wunderbar.

Jemand anderes Problem machen.

Die Tests für das, was ich gerade daran arbeite, die lasse ich lokal laufen.

Aber so eine volle Testbatterie soll woanders laufen.

Ja, aber auch das ist vielleicht ein guter Punkt für Marx, also ne, um Tests zu markieren nach verschiedenen Themen oder sowas, dann kann man halt nur Tests laufen lassen für das einzelne Topic oder so.

Ja, aber ich meine, wenn du entwickelst hast, machst du das ja meistens, dass du einfach sozusagen entweder nur den einen Test, von dem du weißt, dass er halt betroffen ist, irgendwie laufen lässt oder halt eine Gruppe von Tests, die da außen rum sind.

Genau, aber genau, die Frage ist halt diese Gruppe, ne?

Weil wenn du die thematisch kopierst und die vielleicht nicht an demselben Ort liegen irgendwie, wenn man halt da, man kann ja die Tests, das ist auch eine Frage der Philosophie, ob man sie ein Testverzeichnis schreibt oder an die Applikation oder an die kleinen Apps, wo die zugehören oder so, ne?

Und wenn die dann halt so distributed sind und dann willst du aber trotzdem viele verschiedene davon zusammenlaufen lassen, weil die mit der Funktionalität dann doch irgendwie zusammenhängen.

Also ja, also auch da eine Frage, kann man sich über die Architekturgedanken machen, gibt es vielleicht doch Gründe, das dann so zu machen oder, ne?

Und mit diesen Markern, die man da bei Pytest drüber setzen kann, dann kann man ja einfach die gruppieren.

Recht einfach.

Finde ich gar nicht so schlecht für diese Fälle.

Ja, mache ich jetzt weniger.

Ich habe einen Marker einfach für alle GUI-Tests.

Sowas halt.

Das halt wirklich projektübergreifend sind Tests, aber die nutzen irgendwelche GUI-Dinge und die testen einfach nur Python-Code.

Aber ansonsten ja, ich kann mir jetzt vorstellen, so bei einem Enterprise-Projekt, ich kenne auch Kunden, die das so machen, da dann wirklich so eine Use Case-Nummer oder so noch dranhängen und dann sagen, alle Tests irgendwie zu diesem Use Case laufen lassen.

Aber ansonsten finde ich, reicht eigentlich diese Unterteilung in Module.

Ja, also je modularer man ist oder je modulitischer man so eine Anwendung baut, dann müsste man vielleicht tatsächlich diese einzelnen Funktionalitäten so ein bisschen so Multilad voneinander.

Ich weiß, also bei mir reicht auch diese Trennung in Dateien eigentlich, ehrlich gesagt, aus.

Ich habe dafür eine Marker schon verwendet, aber nicht dafür.

Aber genau, das ist eine interessante Frage, was ich jetzt auch, also einfach alles Tests in einem Testsdirectory drin haben oder halt neben die Module im Code legen.

Das sind ja auch zwei unterschiedliche Möglichkeiten.

Ich habe beides auch schon gesehen.

Und ich persönlich mag es lieber, irgendwie das alles in einem Testsverzeichnis zu haben.

Ich mache tatsächlich beides.

Also ich habe ein Testverzeichnis, wo so die Grundlegenden Sachen drin sind, wie Kernfunktionalität, die Clients für Authentication, die Nutzer und sowas.

Und der Testrunner und diese ganzen Sachen und die Hauptfixtures.

Auch witzig manchmal auch meisten anderen Fixtures schon.

Das heißt, Fixtures für Modelle lege ich mit in das Hauptverzeichnis rein.

Aber die Tests selber, also die einzelnen Units für Routen zum Beispiel, die sind mit in dem API-Verzeichnis zum Beispiel oder in der App von Django oder so.

Da muss man die halt importieren.

Einfach in den Kopftest, die man halt da nutzt und dann kann man aber direkt da die Tests schreiben, wo die Anwendung quasi liegt.

Man muss nicht die ganze Zeit durch das ganze Directory so hin und her traversen.

Okay.

Und man kann halt auch modular arbeiten und die Leute wissen halt direkt, dass die Tester dazugehören und man vergisst dann nicht für welche Module.

Man kann halt auch einmal direkt sehen, sind die Tests für die Module jetzt schon da drin oder welche Tests für die Module gibt es denn da.

Manchmal finde ich so einen Test auch sehr nützlich, sowas als Dokumentation für den Code.

Wenn ich manchmal nicht mehr so genau weiß, was passiert denn da jetzt eigentlich oder was sollte da passieren, gucke ich mir den Test an und wenn er gut geschrieben ist, sagt der Test, testet ja die Logik, was da passieren sollte.

Und dann lese ich einen Test, ah, so war das.

Und dann, das macht viel Sinn.

Das mache ich tatsächlich auch ganz oft.

Oft, wenn ich halt irgendwo einen Bock in einem Python-Projekt finde, der sich nutze, dann versuche ich den halt mal kurz zu beheben.

Und dann schaue ich mir oft auch mal irgendwie jetzt bei einem fremden Open Source-Projekt erstmal die Tests so ein bisschen an, um mehr ein Gefühl zu kriegen, was da passiert.

Wenn es dann welche gibt.

Ja.

Ja, das ist tatsächlich auch eine der Sachen, die oft runterfällt.

Ich mache das tatsächlich aber auch so, wie das die PyTest-Dokumentation, glaube ich, auch empfiehlt, dass ich einfach ein Testverzeichnis habe und dann da quasi so eins zu eins das Spython-Package gespiegelt.

Python Utils ist auch noch so ein.

Ich fand Pythest-Dokument war eine der schwierigeren Dokumentationen, die ich lesen durfte.

Im Laufe der Männer so Python kriegt.

Ja, gut, es ist halt auch kompliziert.

Ich habe da sogar diesen, ich habe da so diesen Curse of Knowledge halt.

Ich kenne das so unter diesem Begriff, dass es halt echt schwierig ist, wenn man das alles schon verinnerlicht hat.

Ja, ich verstehe das.

Das nochmal so in den Augen eines Neulings anzuschauen.

Also dass man wirklich einfach verstehen kann, was denn da passiert, sodass das so eine hohe Kunst, glaube ich, ja.

Und das war also bei Python, ich muss auch sagen, mittlerweile ist es einfacher, also die Loku zu lesen, aber manchmal so, hä, was wollen die denn jetzt und warum?

Und dann waren noch so ganz viele Fragen offen.

Die haben dann irgendwie ganz viel Knowledge halt auch tatsächlich vorausgesetzt, dass man sich halt irgendwo an irgendwelchen anderen Stellen so zusammenklauben musste.

Und wo musste man dann selber finden und so?

Und das war schon steil.

Aber ja, also was noch vielleicht so coole Funktionalitäten von Python, ich glaube für ja, es gibt noch jede Menge Plugins, die wir noch vielleicht erwähnen können.

Ich würde eins gerne herausfinden, VCR, also irgendwie so Videorecalling auch noch.

Das ist auch sehr cooles, ja.

Was macht das denn?

VCR stellt quasi, wenn du jetzt eine API nutzt, zum Beispiel einen Request, zeichnet das quasi die echten Antworten auf und macht halt quasi einen echten API-Call und schreibt das Ergebnis inklusive aller Header und allem Content und so weiter in YAML-Files rein automatisch.

Und beim nächsten Call nimmst du einfach die und tut halt so, als wäre die echte API-Antwort quasi in der Pfeile drin.

Und dann hast du quasi die echte API-Antwort gemockt, quasi genauso wie sie kommt.

Und du kannst halt Python immer sagen, okay, zieh jetzt mal neu.

Also du bist gerade in einer Umgebung, wo du das ausprobieren kannst, aber du willst ja die APIs auch wegen Quotas und so weiter halt auch nicht ständig fragen, zum Beispiel.

Oder halt auch nur selten oder halt, wenn sich was aktualisiert.

Und kannst aber so halt dann schon gucken, ob die API nach draußen halt auch funktioniert.

Und halt nicht nur so tun, als hast du die API nachgebaut, sondern kannst du halt tatsächlich direkt benutzen.

Ja, ich weiß nicht, ich mache sowas ungern.

Also da gibt es ja auch mal diesen Spruch, ich weiß, vielleicht don't mock what you what you don't own.

Also ich mock lieber meine eigenen Sachen als das externe Geschichten, weil ich.

Ja, aber es ist ja eben vielleicht nicht gemockt.

Das ist recorded.

Ja, aber das, ja gut, das ist ein bisschen Convenience, aber du mockst es im Worte schon.

Ja, ich glaube,

du willst ja willst ja nicht, dass deine Tests wirklich auf die API zugreifen im Normalfall.

Ja.

Also gerade wenn du da irgendwie ein API-Key brauchst, irgendwelche Credits hast oder die API was ganz Schlimmes macht, dann musst du die ja irgendwie mocken oder irgendwie.

Ja, aber ich würde sie an der Stelle mocken an einer internen, sozusagen, bevor ich das aufrufe und die dann gar nicht aufrufen.

Achso, meinst du?

An der Stelle, wo ich halt noch weiß, was das ist, sodass ich halt auch weiß, wenn ich das ändere, dass ich dann auch den Mock ändern muss.

Aber wenn einem externen, wenn ich das einfach nur automatisch mogge, mocke, dann weiß ich ja gar nicht, wenn sich da jetzt irgendwas geändert hat, okay, muss ich meine Mocs anpassen irgendwie, das kriege ich ja nicht sozusagen direkt mit.

Gut, am Schluss ist dein Code ja so oder so kaputt, wenn sich an der API wirklich was

ändert hat.

Ja.

Was ich einen schönen Ansatz finde da, ist, dass man, um vielleicht auch nochmal bei den Plugins einzuhängen, ist sehr einfach, Py-Test halt eben irgendwie zu erweitern und unter anderem auch ein eigenes Kommandozeilen-Argument zu PyTest hinzuzufügen.

Und was man dann machen kann, ist theoretisch zumindest, ich habe jetzt nicht ein Projekt, wo ich das effektiv mache tatsächlich, eine Kommandozeilen-Option Real API oder sowas hinzuzufügen und dann halt zu sagen, wenn ich das mitgebe, laufen einmal meine Tests gegen die richtige API durch.

Anstatt gegen meine recordeten Antworten.

Ja, das konnte man natürlich machen, ja.

Wir sollen je nach API halt sagen, das können wir auch auf einer CI irgendwie wöchentlich oder monatlich oder sowas mal ausführen.

Ja, also ich finde es super spannend, also das macht es halt echt coole Sachen möglich.

Man kann ja auch seine eigene API quasi mit aufnehmen oder sowas, wenn man das möchte.

Und dann hat man auch schnell so Mock Fictures da, die man halt nicht selber bauen möchte.

Selbst wenn du sagst, okay, du möchtest gerne vorher das mocken, aber ich finde das schon ziemlich gut.

Ja, gut, nee, kann ich auch sagen.

Man kann das sogar abusen.

Wenn man sich viele Zeugs irgendwie abspeichern will von irgendwelchen Scrapern oder sowas, könnte man das tatsächlich einfach einsetzen, um sich die API-Calls einfach mal wegzushapen und das relativ easy.

Ja, ich hasse.

Also genau, das sind etwas, ich überlege gerade, was ich an Plugins normalerweise verwende.

X-Tist verwirche ich tatsächlich.

Aber das muss man ja, wenn man irgendwie Tests parallel ausfinden lassen möchte.

Da kommt aber noch viel mehr Zock mit dabei.

Ich bin manchmal nicht so ganz sicher, ob ich das alles haben will.

Aber was ich auch oft benutze, also was ich total super finde, ist PyTest-Mock zum Beispiel, finde ich super.

Da ich mit Unitests, immer wenn ich Unitest-Geschichten irgendwo mache und dann türmen sich so die Patch-Dekoratoren oder ich ganz viele Kontextmanager und dann ist Pytest-Mock echt total, also sehr angenehm.

Was macht das?

Das übernimmt, es macht das halt automatisch.

Du kriegst halt einen Mocker in, schreibst du als Fixture sozusagen in deinen Test und dann rufst du halt Mocker.patch irgendwie einfach auf, musst aber da nicht einen Kontextmanager drumherum machen oder irgendwie das als Accurator verwenden und kannst das halt auch mehrfach aufrufen, ohne dass du da halt irgendwie dann eine Verschachtelung von Kontextmanagern hast.

Und das wird halt hinterher auch wieder alles entmocked sozusagen, entgtest vorbei ist und so.

Also ich fand es immer so, ich fand's, ja, du hast recht, das ist für viele Sachen ganz nett, aber ich find's auch irgendwie hässlich.

Ich weiß nicht mehr genau, warum.

Ja, diese API halt von unitest.mock, die macht schon irgendwie ganz viel Magic.

Da bin ich auch nicht so wirklich zufrieden damit irgendwie.

Und ja, das Plugin ist eigentlich nur ein relativ dünner Layer darum, um das halt zu einer PyTest-Fixture zu machen, zum einen.

Und zum anderen, wenn dann was schief geht, man kann diese Mock-Objekt ja dann im Nachhinein fragen, wurdest du jetzt so und so aufgerufen.

Und wenn was schief geht, nochmal PyTest einzuhängen, dass man halt diese den schöneren Output von PyTest kriegt, der dann auch die Werte vergleicht und sowas.

Aber viel mehr als das macht das Plugin eigentlich nicht.

Aber schöner Output, PyTest-Witch natürlich.

Ah, okay, ja.

Ja, das ist ja überhaupt, das hatten wir noch gar nicht so richtig.

Finde ich jetzt eigentlich fast das Hauptfeature von PyTest für mich jedenfalls, dass halt die, dass man einfach so Assert hinschreiben kann und das halt funktioniert und man halt trotzdem sehr schöne Ausgabe kriegt, die einem zeigt, wo ist genau was unterschiedlich und so.

Das ist, das ist halt sehr, sehr angenehm.

Nicht so komisch, dass das After Ich will den Camel Case und jetzt.

Da ist aber auch übrigens eine ordentliche Portion Magie da.

Ja, ich fürchte auch irgendwie, ja.

Weil an sich dieses Assert-Keyword von Python, das macht einfach nur einen Asssertion Error.

Also ohne jetzt, dass man irgendwie Zugriff hat auf Infos, was da passiert ist.

Python macht da eben sein Rewriting.

Ja, und durch den Dekoder.

Das ist ein Abstract Syntax Tree, was Python aus so einem Modul generiert intern, bevor das wirklich dann zu Python-Bytecode wird.

Das passiert das beim Import der Testmodule irgendwie, ne?

Da wird das mit der Bytecode dann.

Nicht der Bytecode, sondern halt ein Level vorher, den Abstract Syntax Tree, da injectet dann PyTest noch seine eigenen Calls, um da quasi einmal festzuhalten, was ist da eigentlich drin in dieser Assertion.

Ja.

Ja, das sind viele Dinge, wo ich sagen muss, es genau ist sehr viel Magie, aber irgendwie so unterm Strich halt auch sehr angenehm.

Also hat sich irgendwo bewährt.

Es entspricht diesem Pythonic-ästhetischen Ansatz, irgendwie, das in klarer Sprache hinzuschreiben, was das machen soll.

Und das Assert ist da für Tests, glaube ich, sieht einfach schick aus.

Ja, aber wäre das jetzt nicht auch schick, wenn man, wenn Assert an anderen Stellen genauso funktionieren würde?

Vielleicht denken ja Leute, wenn sie das in Python verwendet haben, ah, das funktioniert ja immer so und machen das dann irgendwo anders und dann.

Naja, das ist halt sieht das plötzlich ganz anders, als

ich mir gedacht habe.

Ja, aber man kann ja zwar Assert ausschalten, wenn man das richtig aufruft, den Interpreter.

Aber normalerweise macht man das ja nicht und normalerweise fährt Assert dann halt einfach mit dem Assertion Error auf die Nase.

Ja, ja.

Aber in Python sieht das dann ja anders aus.

Naja, aber das ist eigentlich relativ klar, oder?

Dass halt, wenn ein Test fehlt, dass der Assertion Error dann mit mehr Informationen auch zurückgegeben wird.

Also das macht er ja schon.

Also der im Prinzip im Failender Python-Test heißt, du hast einen Assertion Error.

Nee, nee, nee.

Ja, aber Python Test macht dann halt eine Menge Dinge.

Ja gut, aber das ist ja, dafür ist ja das Framework ja da, glaube ich, dass das.

Da wollte Ronnie Pfunchmied, auch einer der Maintainer, wollte da auch mal irgendeinen Pip schreiben oder sowas, dass man sich eben bei Python gerade schön reinhängen kann in diese Assertions.

Ja, das wäre...

Das wäre schon ganz nützlich.

Das ist für irgendwie so eine Assertion-Lib oder sowas, die man einfach importiert und dann hat man schönere Assertions oder so.

Das wäre doch cool.

Aber ja, wahrscheinlich ist nicht so ein.

Aber ich glaube, daraus ist leider nie was geworden.

Was es gibt für Notebooks vielleicht noch ganz interessant.

Ein Ding namens iPy-Test, was eben PyTests in diese Notebooks integriert.

Also man kann einfach mit Prozentprozent iPy-Test, kann man halt Py-Test ausführen und hat dann auch Zugriff gleich auf die lokalen Variablen aus dem Notebook und sowas.

Und das, wenn man das einmal einrichtet in einem Notebook, dann kriegt man auch in diesem Notebook global quasi geschenkt die Assertion-Infos, wenn eine Assertion fail schlägt.

Ach, und das geht dann auch an anderen Stellen sozusagen dann, ah ja.

Genau, das hängt sich dann halt da irgendwie ein.

Ach cool, das kann ich auch noch nicht.

Ja.

Und noch mehr Plugins hier benutzt?

Will ich nochmal free-scannen, wenn ich irgendwie so Zeit sagen will, Auto während der Zeit oder die Zeit muss ich jetzt um zwei Stunden verschieben zwischen zwei Tests oder sowas.

Das ist ganz nett.

Mit Kontextmanager oder so.

Das ist cool.

Ja, das habe ich schon genutzt.

Responses.

Oh ja, ja.

Das ist Mocking halt für Requests.

Man ruft eigentlich im Prinzip, wie man Requests aufruft, ruft man halt erstmal Responses auf und das mockt einem das weg.

Ich glaube, das gibt es auch für HTTPX, wenn ich das richtig gesehen habe.

Und da, ich fände es eigentlich schön, wenn es mehr so Mocking-Libraries gibt.

Also was wir jetzt eben FreezeGone, VCR, Responses oder diesen HTTPX-Mock.

Ich bin eigentlich der Meinung, jede Python-Library, die irgendwas macht mit externen Systemen, also auch sowas wie PySerial beispielsweise, sollte halt gerade auch irgendwie so Test-Support oder so Mocs gleich mitliefern und dann auch schöne maintained getestete Mogs.

Mocking ist immer noch sowas, das macht man irgendwie so ad-hoc in jede Test-Suite wieder neu das Rad erfunden.

Ja, das ist natürlich auch, ja.

Das stimmt.

Es ist relativ viel Zeit immer dann, bis man das, dass das richtig läuft.

Das ist wahrscheinlich sogar der Hauptteil, den man braucht für Testschreiben, oder?

Nö, das würde ich jetzt auch nicht sagen.

Aber es ist halt immer wieder etwas.

Was ich noch gerne mache, ist Insta-Fail.

Und dann sieht man halt direkt, wenn die Tests ein bisschen länger laufen und die Tests, die fällen schon mal, kann daran schon mal dran werkeln, wenn man einfach nur keine Ahnung sich verschrieben hat, vertippt hat oder so, hat man den schon mal dann drauf und das läuft dann trotzdem noch.

Ich nutze noch, da bin ich jetzt nicht so stolz darauf, aber ich nutze noch PyTest Rerun Failures, wo man Tests halt als Flaky markieren kann und wenn sie fehlschlagen, werden sie halt nochmal ausgeführt.

Weil ich bei Qt-Browser halt wirklich aus GUI-Applikationen mit so vielen externen Komponenten dieses Problem mit Flaky-Tests fast nicht in den Griff kriege.

Und dann hat bis zu irgendwie einer Assertion Failure in der Libc, also so die Library-Libc selbst implementiert.

Wo ich sagen muss, dass mir jetzt so viele Labels darunter, da kann ich jetzt echt nichts daran ändern.

Also was will ich machen?

Ja.

Aber natürlich nur so jedes tausendste Mal.

Ja, das ist halt ganz mies, wenn irgendwie so ein Test nur jedes hundertste oder so Mal fällt schlägt, das ist ja ganz eklig.

Irgendwie so, um das rauszufinden, das

ist immer.

Ja, war das auch, ist das ein Plugin oder kann das ein paar Tests, das weiß ich gar nicht, aber dass man die Reihenfolge irgendwie zufällig macht, random Partner ist?

Oder irgendwie so

gibt es ein paar randomly gibt es.

Randomly, ja.

Ja.

Genau, ja, macht eigentlich Sinn, weil eben Tests voneinander unabhängig sein sollten.

Und andersrum gibt es PyTest Order, wo man sagen kann, Tests sollen halt voneinander abhängig sein in einer bestimmten Reihenfolge.

Wie heißt das?

Kannst du auch mal getrunken, ne?

PyTest Order, glaube ich.

Da kommt oft die Frage dann eben von Kunden von mir, die dann irgendwie Elektronik mit PyTest testen.

Weil da natürlich, wenn man jetzt eine Klimakammer hat oder so, ist das halt nun mal so, dass die Dinge voneinander abhängen.

Oder dass man vielleicht alle Tests, die irgendwie bei 30 Grad laufen sollen, dass man die erstmal laufen lassen will, anstatt jedes Mal auf minus 10 Grad runterzukühlen und weder hoch auf 30.

Oder wie auch immer.

Macht wahrscheinlich Sinn.

Ja.

Ja, Python BDD nutze ich noch.

Ah, okay, das ist interessant.

Ja, da habe ich auch schon häufiger was schon gehört, aber so.

Ich habe es auch mal versucht zu nutzen.

Also, vielleicht nochmal kurz Behavior-Driven Development Tests, glaube ich.

Man kann so Logik, so Business-Logik schreiben, so für den PO oder so.

Und er kann dann so Sätze formulieren in seiner eigenen Sprache und dann guckt Python-BD, ob es geht oder nicht.

Aber so tief.

Das ist im Prinzip einfach nochmal eine kleine Abstraktion, dass man sagen kann, given I have an author user, when I do this and that, then this and that should happen.

Also mit diesem given when then, das halt wirklich als Testsprache hat und dann die Implementation der Tests eigentlich nochmal abgekapselt hat von den Test Cases.

Also quasi so diese User-Story reingießen, ja.

Also ich habe es wieder rausgeschmissen, ich hab's ausprobiert, aber irgendwie, wahrscheinlich lag es aber auch an einem Projekt halt, wo das halt nicht so wirklich dazu gepasst hat.

Wofür verwendest du das?

Ich nutze es halt ganz stark für die End-to-N-Tests für Kube-Browser.

Jetzt müsste ich da vielleicht nochmal kurz einhalten, was KubeBrowser denn überhaupt ist.

Jetzt habe ich es schon ein paar Mal erwähnt.

Das ist so mein Hauptprojekt seit ziemlich genau zehn Jahren.

Ich glaube in drei Tagen oder so sind es zehn Jahre.

Und zwar ein Webbrowser, der sehr stark auf Tastaturbedienung ausgelegt ist, so inspiriert von VI bzw.

Wim, eben auf Chromium aufsetzt und in Python geschrieben ist.

Und darüber bin ich danach zu PyTest gekommen.

Und das hat halt dann so ein Interface mit einer Command-Line quasi eingebaut.

Und da habe ich dann halt auch viele N-to-N-Tests, wo ich halt einfach irgendwo ein Kommando hinschicke zu einem laufenden Browser und dann erstmal schaue mit einem Webserver, der direkt im PyTest-Prozess läuft, wurde dann die und die Seite aufgerufen oder ist das und das passiert.

Und so diese N-to-N-Tests habe ich dann halt eben mit diesem PyTest-BDD geschrieben, dass ich sage, wenn I run Open und irgendwie ein Pfad, dann this und that Page should be loaded.

Ja.

An der Stelle klingt das durchaus sinnvoll, weil wahrscheinlich hat man ja ganz viele davon und da will man ja wahrscheinlich dann nicht immer das ganze Boilerplate schreiben.

Ja, ich weiß auch nicht, ob ich es nochmal so machen würde, weil es sind jetzt halt doch sehr viele so End-to-End-Tests geworden und da auch ein witziges Problem mit Flakey Tests und mit langsamen Tests.

Aber ich glaube, für so gewisse Dinge lohnt sich das schon.

Also ich fand es auch ganz angenehm, wenn halt neue Leute dazukommen, die noch nie was mit Pythons gemacht haben.

Dass du denen sagen kannst, guck, schau dir das mal an.

Das ist eine schöne, eine hohe Abstraktion, nochmal höher als Python-Code und schau mal, ob du so einen Test schreiben kannst.

Ja.

Ja, an der Stelle ist vielleicht auch noch ganz interessant, genau.

Das ist ja auch, selbst wenn man jetzt nicht BDD-Tests sozusagen so hinschreibt, sondern normale Tests, dann empfiehlt es sich da ja auch vielleicht, sich im Grunde an dieses Pattern zu halten.

Also genau, given when then, ist halt die eine Formulierung, wie man das halt ausdrücken kann.

Es gibt noch eine andere, die nennt sich irgendwie Arrange Act Assert, aber es ist im Grunde beides das gleiche.

Es ist halt immer irgendwie, man baut sich zuerst irgendwie ein State zusammen, der halt irgendwie ist und dann macht man irgendwas drauf und dann guckt man hinterher, ist das rausgekommen, was man sich irgendwie, was man erwartet hat und wenn nicht, ist halt schlecht.

Aber es macht halt ja Sinn, Tests immer so zu strukturieren, dass man halt auch, wenn man jetzt auf den Test guckt, sofort weiß, okay, ach, das an der Stelle wird nur irgendwas zusammengebaut, an der Stelle wird jetzt der eigentliche Aufruf gemacht und hier erst hatten wir irgendwelche Dinge, wo wir dachten, das müsste jetzt da rauskommen.

Also das BDD, das klingt auch so ein bisschen nach, als könnte man das mit Playwright machen.

Ich weiß nicht, ob das dieses Pattern auch ist, lieber Jochen.

Die Playwright-Tests, die ich bisher gemacht habe, nee, die waren halt einfach, da habe ich das alles immer von Hand hingeschrieben.

Ja.

Es ist halt, ja, also macht aber so ein bisschen BDD auch, oder?

Also es gibt halt so einen Browser und sagt halt, okay, geh auf diese Seite und drück mal so einen Knopf und ihr wartet das.

Ja, aber es sind schon einfach Funktionsaufrufe, ist nicht irgendwie Text, den man hinschreibt.

Ja, okay, stimmt.

Ich wache es halt anders, die es halt direkt abheißen, ja.

Ja.

Ja, ich glaube, ich, also mir fällt kein Plugin mehr ein, was ich jetzt empfehlen wollen würde.

Fake hatten wir ja schon.

Was ich mich frage, ob es sowas gibt, ich weiß nicht, in der JavaScript-Welt, dass sehe ich halt ab und zu mal, gibt es halt auch so Dinge, da läuft halt einfach immer irgendwie ein, also da wird halt halt geguckt, ob sich irgendwas an den Files geändert hat und wenn, dann läuft halt da irgendwie der Testrunner quasi die ganze Zeit und läuft alle Tests, die dann halt sozusagen davon beeinflusst sein könnten von irgendeiner Änderung, werden dann halt nochmal ausgeführt.

Und das gibt dann in einem so eine Art Dashboard, was halt gerade nicht funktioniert oder was funktioniert.

Gibt es das für Py-Tests eigentlich auch?

Weil ich glaube, sowas habe ich noch nicht gesehen.

Ja, es gibt Testmon.

Ah, okay.

Cool.

So ein Projekt, ein größeres Projekt, Testmon.org.

Hatte ich mir mal angeschaut, aber jetzt auch schon lange nicht mehr.

Ein paar linken wir mal, gucken wir nochmal rein.

Ich weiß, dass es auch ein, zwei Leute gibt, die jetzt da so ein bisschen noch schauen, wie kann ich mit Coverage halt auch dann schauen, welche Tests wirklich beeinflusst sind von der Änderung und sowas.

Aber es ist schon noch so etwas, was es jetzt nicht so in fix fertig ist.

Es gibt es schon in fix fertig, aber es ist auch noch was, was ich weiß, dass Leute dann arbeiten.

Ja.

Ja, ansonsten, ich weiß nicht, was haben wir denn noch so für Themen?

Noch irgendwie größere Dinge gar nicht besprochen oder.

Ja, vielleicht noch den Development Sprint.

Und zwar gab es im 2016, glaube ich, mal einen Development Sprint, wo wir uns alle mal getroffen hatten in Freiburg im Breisgau und halt mal zusammen rumgehackt haben an PyTest.

Zum einen halt eben so die üblichen Verdächtigen, die Core-Entwickler, zum anderen aber auch ganz viele Leute von irgendwelchen Plugins oder auch einfach Leute, die mal was an PyTest machen wollten.

Und ich bin gerade daran, fürs 24 sowas wieder zu organisieren.

I müsst wahrscheinlich mal noch schauen, dass ich das auf die PyTest-Webseite auch mache, weil bisher war die Resonanz nicht so viel.

Ich hab da halt mal von auch einem Kunden von mir das Angebot bekommen, dass die uns da hosten bei sich in Vorarlberg.

Was erstmal so im Nirgendwo ist.

Vorarlberg nach

Alpen irgendwo.

Ja, das ist tatsächlich ziemlich nah.

Als Österreich, aber gerade an der Schweizer Grenze.

In einem Dorf mit irgendwie 3000 Leuten oder so.

Sind die zu Hause.

Omikron heißen die.

Und die hatten mir angeboten, das halt da zu hosten und hatten noch, meinten noch, ja, wir können da gratis essen und so und haben Sitzungsräume und sowas.

Und da hatte ich jetzt mal so eine Umfrage gemacht, wer dann so kommen will und es haben sich halt irgendwie fünf Leute oder so gemeldet.

Ich würde eigentlich ganz gerne ein paar mehr Leute noch haben.

Also letztens eben in 2016 waren es 27 Leute.

Diesmal könnten wir schon so 30, 35 oder so, könnten wir hosten.

Wahrscheinlich dann auch mit Preise teilweise bezahlt und sowas, Unterkunft teilweise bezahlt.

Müssen wir sich alles im Detailer anschauen, wenn wirklich die Resonanz auch da ist.

Ja, cool.

Also da kann man sich auf jeden Fall mal melden, wenn man da Interesse hat.

Wann wäre das denn ungefähr im Jahr eher so im Sommer?

Genau im Juni.

Wir haben zwei Wochen.

Schon mal ganz gut.

Genau, Mitte, Ende Juni sowas.

Müssen doch schauen, welche Woche das wert.

Und dann wäre eben so die Hoffnung, dass wir da Leute zusammenkriegen, die irgendwas machen wollen.

Jetzt ohne eine fixe Idee zu haben, was genau, es kommt da mal alles noch.

Aber halt einfach so ein Development Sprint wieder mal zu haben und sich mal wieder in Person zu sehen auch.

Ja, gute Sache, das ist immer super sowas, ja.

Ja, was gibt's noch?

Ich würde sagen, mit Py-Tests sind wir, glaube ich, mit den Themen, die ich zumindest auf der Liste hatte, so weit.

Dann können wir vielleicht zu den Picks der Woche des Monats der Folge übergehen.

Ja, können wir gerne machen.

Alles klar, da mache ich mal.

Kapitelmarke.

Picks.

Upsi.

Also ich pkf-string.helpe.

Aha, mich geehrt.

Ich glaube, ich hatte das auch schon mal irgendwann gepickt, meine ich.

Aber müssen wir gucken.

Wir picken immer nur noch Sachen, die wir schon mal.

Sonst fällt nichts mehr ein.

Ja.

Ist mir jetzt letztens auch passiert, habe ich es genau in der nächsten Episode nochmal gepickt, was ich schon mal gepickt hatte.

Ja, lass mal überlegen, was würde ich denn picken?

Ah, ich glaube, ich mache mal irgendwas aus dem Data Science Bereich.

Jetzt hat man das am Anfang schon so ein bisschen den Mundwässrig gemacht mit dem Open AI-Thema und dann kam aber überhaupt gar nichts mehr.

Ich versuche mich da wieder so ein bisschen reinzufuchsen.

Ich mache das ja auch, aber in letzter Zeit viel mehr Webentwicklungen gemacht aus, was weiß ich gar nicht warum.

Irgendwie, eigentlich ist er ja auch das große Thema gerade, aber und deswegen habe ich mir auch mal geguckt, was gibt es denn da so an Kursen, wenn man sich jetzt für diese ganzen Geschichten LLM, die Fleuring Kram interessiert.

Und da gibt es einen Fast-Kurs von Fast.ai.

Jeremy Howard macht es, das ist super.

Den verlinke ich dann auch mal in den Shownotes.

Tatsächlich.

2022 und 2023.

Ich weiß nicht, ob es die 23 schon gibt, aber die 22 ist auf jeden Fall, ich glaube, die habe ich.

Eigentlich müssen wir dazu eh nochmal eine Folge machen.

Ich würde sagen, der Einstiegskurs ist vielleicht sogar CS50 AI with Python für die Leute, die so ein bisschen mehr anfangen.

Die Grundlagen irgendwie.

Und dann parallel mit der Video-Tutorial-Serie von Enrique Carpasi, ein Fast AI.

Ja.

Würde ich sagen, dass dann ist meine Data Science schon mit der Nase ganz schön tief drin.

Wenn man so ein bisschen noch Statistik macht, vielleicht dann.

Oh, und dann picke ich vielleicht, dass ich die andere Geschichte, die ich mir auch aufgeschrieben hatte, gleich mit.

Es gibt eine super schöne Visualisierung von, wie funktionieren diese LLMs eigentlich, wo man halt sieht, wie ein Token irgendwie oben so grafisch irgendwo reinfällt und dann halt irgendwie in Embeddings umgewandelt wird und dann durch diese ganze Maschinerie durchläuft, dann kann man auch noch auswählen, welches Modell hätte man gerne.

Und wenn man das mit tatsächlich, oh, das ist aber eine beeindruckende Visualisierung und naja, das ist ja bestimmt alles irgendwie nur so, hat sich jemand halt ein Grafiker halt hingemalt oder sowas.

Nein, es ist tatsächlich, sind die echten mehr oder weniger, also gut, vielleicht nicht in jedem letzten Detail, aber es sind schon fast die schon quasi die echten Modelle und da hat jemand sich echt Mühe gegeben und in WebAssembly die ganzen Operationen alle nachimplementiert und das ist schon großartig.

Es gibt auch den Source dazu.

Ja, ist halt hauptsächlich TypeScript und WebAssembly.

Du meinst aber nicht Manima ML.

Many ML.

Nee, wüsste ich jetzt nicht.

Also es ist halt einfach so grafisch.

Man sieht halt quasi, wie so ein Ergebnis von so einem Modell berechnet wird.

Halt grafisch.

Und wie heißt das?

Also ich kenne Money Mail.

Weil da muss ich mal gerade nachgucken, ob das genauso heißt.

Da kann man.

Das heißt einfach nur LLM-Visualisation.

Ah cool.

BBCroft.net.

Also was man mit Money Mill kann man quasi seine eigenen Sachen auch bauen, weil man, da kann man sich auswählen, welche Layer man in sein neural-Netwerk reinsteckt und dann sowas bauen.

Oh, das sieht aber auch schick aus, was du da sagst.

Ja, gut, kann man jetzt nicht sehen, wenn man es nur hört, aber.

Ja, ja, Jochen hat es gerade aufgemacht auf dem Screen.

Das sieht sehr nice aus.

Das bitte auch einmal linken.

Genau, das hätte ich dann halt auch nochmal verlinken.

Okay.

Ja, dann machst du Moneymil direkt noch dazu, dann haben wir beide.

Okay, mach ich dann auch.

Ja.

Florin, hast du auch einen Pick?

Ja, ich hatte erstmal gar nichts und jetzt sind mir da gleich zwei Dinge eingefallen.

Ah, sehr gut.

Zum einen, als du Data Visualization erwähnt hattest, eine Webseite, die ich letztens von einem Kollegen gekriegt habe, datatuwith.com, was einem so durchleitet, wenn ich eine gewisse Art von Daten habe, also jetzt irgendwie numerische Daten, zwei Variablen ordered, was mir halt anzeigt, wie plot ich das am schönsten.

Mit danach Links zu irgendwie Python-Example-Code und sowas.

Ja, schick.

Das war das eine.

Das andere ist die Ewall Game.

Ich weiß nicht, ob ihr das mitbekommen habt mit The Password Game.

Eine Webseite, wo man halt ein Passwort eingeben soll und dann kommen mehr und mehr Regeln dazu, das irgendwie, um sein dann unmöglich zu machen.

Und basierend darauf.

Das Passwort game will ich auch.

Und basierend darauf hat jemand halt The Eval Game gemacht, wo man eine Python-Expression eingeben muss, die dann immer mehr und mehr Regeln folgen.

Ach ja, okay, interessant.

Das klingt gut.

Ja.

The digits and your password must add up to 25.

Sehr gut.

Großartig.

Sehr gute Idee.

Ja, nee, vielen Dank.

Das klingt auch super.

Ja.

Ja, ich glaube, dann sind wir überhaupt auf du.

Wie denkst du da was, Florian?

Ich fand's sehr schön.

Ja, danke euch.

Viele Dinge, die ich noch nicht wusste.

Teil, glaube ich, von dem, was wir so machen.

Auf jeden Fall.

Ja, dann danke Florian.

Bleibt uns alle gewogen.

Danke, Jochen.

Schaltet ein, wenn ihr mal wollt, wenn ihr irgendwas noch wissen wollt, Fragen habt, Anregungen, Kommentare.

Vielen Dank auch für unsere lieben Hörerinnen und Hörer, die uns Fanposts schicken oder Fragen stellen und so, das ist immer sehr nett.

Hallo.peisenpodcast.de könnt ihr uns erreichen.

Dann bis bald und ein gutes Jahresende, kann man ja fast schon sagen.

Wir sind ja bald schon im sechsten Podcast, ja, Jochen.

Ach du hier mir nicht, echt?

Ist das schon so lang?

Ja.

Hoi.

Jetzt bin ich ja noch älter als mit normaler Sohnfühler, aber gut.

Heißt also, die Folge muss jetzt noch dieses Jahr rauskommen.

Das wird aber auch noch funktionieren, denke ich.

Weiter abkommen.

Element, das gleiche auch nicht.

Ja, schauen wir mal.

Also, vielen Dank für eure Aufmerksamkeit.

Ja, ebenso.

Ciao dann.

Tschüss.

Tschüss.