Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast, Episode 53 mit PyTest.
Hi Jochen.
Ja, hallo Dominik, willkommen.
Ja, mein Gott, und zwar den Florian. Hey Florian.
Hallo, hallo zusammen.
Ja, wir haben heute Masse öfter mal was mit PyTest und da haben wir gedacht, dann fragen wir dich doch einfach mal, ob du mich 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
vielleicht fünf Minuten dazu reden.
Ich mache tatsächlich
so fast Vollzeit
Open Source
und zwar kam das
nicht vom PyTest ursprünglich, sondern von
einem anderen Projekt von mir, von
Qt Browser, kann ich gleich
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 QBrowser um PyTest
durch Spenden finanziert
und zum anderen gebe ich im Herbst
jeweils hier an der Fachhochschule
Python-Unterricht für Erstsemesterstudierende
also Bachelor
Informatikstudierende
Also ja, ganz viel Open Source
ganz viel auch
Freiheit, sage ich mal, wann ich
was mache und eben auch viel PyTest
Ja genau, du bist einer der
PyTest-Maintenner auch
Genau
Das hat auch ganz lustig schon angefangen
Ich hab da halt eben durch
Cube Browser, durch das Projekt reingekommen
weil ich da Tests geschrieben hatte
dafür, damals noch mit
Unitest Framework von Python
was mit Python mitkommt
und
da gab's 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, auf 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
in der PyTest-Serie.
Vielen Dank für den Einsatz
War aber diesmal sehr entspanntes Update
Hat alles gut funktioniert
Nicht wie deprecated
Was die Verbesserung angeht
Es gibt ein tolles neues Ding
Ein Bug, der seit 18 Jahren offen war
Ein Issue, der seit 18 Jahren offen war
Der jetzt geschlossen wurde
Da ging es darum, dass er eigentlich blöd ist
Wenn man bei einem Modelfield
Default angibt
Dass das nur dann ausgefüllt wird
Wenn man 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 ByCreate
und man kann halt auf
verschlungenen Wegen irgendwie Dinge erzeugen in der Datenbank.
ByCreate 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,
dann kann es gut sein, dass das nicht passiert.
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
und ohne das halt über die Save-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 Blog-Eintrag zugeschrieben.
Ja, gibt's auch ein Video, hat sie
dazu gemacht. Genau, die macht ja hier auch die
PyColon-Meetup-Gruppe
organisiert sie mit.
Ja, genau.
Also, was jetzt geht, ist halt, dass man
nicht sagt Default in einem Model Field,
sondern DB
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 ist ja
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, das man nur verstehen kann, wenn man
den Applikationscode auch dazu legt, weil
Applikationscode halt
deutlich volatiler ist oft als Datenbankschema.
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
dran zu bauen. Das kann man ja jetzt halt auf eine deutlich
elegantere Art machen.
Generated Field heißt das glaube ich,
einfach Models, Generated Field und dann...
Generated Field ist jetzt die andere Geschichte,
Genau, da kann man dann halt auch so Dinge, manchmal möchte man ja auch irgendwas indizieren können, was halt irgendwie, was halt auf irgendwas basiert, was halt berechnet wird aus unterschiedlichen Spalten, die man halt in der 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 ehrlich gesagt vergessen
was es genau war, es gab einige Verbesserungen
an den Formularen
also man kann jetzt irgendwie
Help Text und
Label und Dinge irgendwie
einfacher benutzen, wenn man jetzt
einzelne Felder als Fieldset einfach verwendet, dann sind
die automatisch glaube ich mit dabei
Genau, das muss man vorher mal ganz umständlich auseinander proben
Ja, und ja
ehrlich gesagt, mehr kann ich mich nicht erinnern
Aber ja
und PyTest.
Organisation ist und
die kontrolliert halt
die kommerzielle Entität, die halt nur deswegen
gegründet worden ist, weil
man halt diese JetGPT-Geschichte auch als
Produkt irgendwie rausbringen wollte und dann 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
berechnen 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
Cloud irgendwie gebaut hat.
Also ein ähnliches Ding ist wie JetGPG, bloß halt
sozusagen von einer 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, hey, das ist nicht okay,
so geht das nicht.
Das könnt ihr ja so nicht machen.
Und dann hat er
sich ans Board gewendet und gesagt,
feuert den CEO mal,
das ist irgendwie nicht okay.
und dann hat das Board drüber nachgedacht
und dann haben sie gesagt, nee.
Und dann hat er gesagt, gut, dann gehe ich jetzt halt und hat ein paar Leute
mitgenommen und dann hat er eine neue Firma aufgemacht.
Und ja, aber das ist jetzt noch gar nicht so
lange her. 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...
Ja, bei dem 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, ich meine, der Name
ist so ein bisschen...
Ja, die Propertäre
und so.
Ja, und natürlich ist halt auch die Frage...
Die Papers 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 halt die Mission von dem Non-Profit
sozusagen der Allgemeinheit irgendwie
zu nutzen.
Ja, wäre mal
schön. Und dann ist halt 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 sieht mit
den großen
Tech-Giganten und halt auch ja von einem von
denen halt ja massiv finanziert wird,
Microsoft hat da irgendwie eine Milliarde
reingesteckt oder so und
halt auch eine Bewertung hat inzwischen von
80 Milliarden oder irgendwie ganz
unglaubliche Beträge und
ja, und dann halt
auch nichts mehr in der Richtung tut, was
halt die Mission eigentlich vorgibt, dann kann ich
und PyTest.
und was AI Act in Europa angeht und so.
Wo man ja auch sagen muss,
Wir sind für ein AI.
Regulierung, sagte der Minister.
Nein, 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...
Das ist für mich ein ganz neues Pass.
Das Pass will man vielleicht nicht aufmachen,
aber dass man das regulieren will,
dass Leute da nicht zu Schaden kommen,
das kann ich durchaus nachvollziehen.
Ja und nein.
Ja, also ich finde das ist, aber das ist ja, da kann man wenig gegen sagen.
Nein, also der Wunsch ist richtig, würde ich sagen.
Ja, also, aber dass man jetzt die Technik selber reguliert, das finde ich halt komisch.
Ja, genau.
Das ist halt irgendwie, und ja, da gab es halt diverse Lobby-Stremungen.
Ja, die Frage ist halt, wie das halt überhaupt geht, ohne dass man jetzt den Stecker zieht oder so.
Ja.
Naja, jedenfalls ist es ja jetzt auch nicht so gekommen.
Es ist jetzt wie die Richtlinie, das ist ja noch nicht unter Sach und Fach.
Es ist ja bloß irgendwie sozusagen, es gibt ein Verhaltungsergebnis.
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, Transparenz regeln wir halt ganz gut, nach dem Motto,
du musst das Modell halt irgendwie veröffentlichen.
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
und PyTest.
überhaupt gar keine Gefahr.
Das ist, glaube ich, kein Problem für die.
Nein, niemals. Warum sollte denn niemals
sich jemand gruppieren lassen?
Ja, also, nee, nee.
Ja.
Und ich meine, das Board hat ja schon gezeigt,
dass sie da absolut in der Lage sind,
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 God, dann was kann man auch wieder spielen?
Ja,
genau, was hat man noch so?
News. Ja, oh, ich...
Du hast noch eine wichtige News für Python.
Für Python, ja.
Ja, genau,
Kill Removal ist beschlossene Sache.
Wer sich dafür interessiert, es gibt da einen schönen, es gibt
einen neuen Podcast, weiß auch nicht, ob wir den schon
erwähnt hatten, CorpyY heißt der,
ist irgendwie von
Lukas Langer und, na,
Pablo
Galindo Salgado
den Release-Manager
für die letzten beiden Versionen
die
machen den und
reden halt über so
C-Python-interner Geschichten
zum Beispiel war das die erste Episode
war über den
C-Python-Core-Dev-Sprint
oder halt andere Themen wie zum Beispiel
dass es dann einen Just-in-Time-Compiler
irgendwie für 3.13
wohl geben soll und solche Dinge
und da gab es jetzt auch eine Episode
über das Entfernen
von Gil, 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.
Das hat mir gar nicht aufgefallen, aber ja, stimmt,
das ist gut.
Weil Cinder X, das ist die letzte Folge,
Die letzte habe ich glaube ich noch nicht gehört
Da haben sie
da haben sie mit Karl Mayer geredet
Karl Mayer, ganz interessanter
Typ 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 er geredet hat, was man so
Probleme kriegt, wenn man halt irgendwie mehr als
deutlich mehr als eine Million Zeilen Python irgendwie hat
und dann eine
Anwendung, die darauf basiert.
Ich glaube, den Artikel hatten wir auch schon das eine oder andere Mal
irgendwo in den Turnus gelinkt, wenn ich mich recht erinnere.
Kann sein, ja.
Also genau, das kann man...
Ja, Kopf, EY, das ist ein 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.
Und da dachte ich, okay, muss ich diesmal auch...
Ich kann mich an den Januar und den Februar erinnern, wo ich
1000 Passwörter umstellen musste, das war super
Wo ich dann gesagt habe, ja, okay
so prinzipiell ist One Password
jetzt auch nicht so viel besser zum Beispiel
aber zum Glück
sind sie noch nicht irgendwie hops genommen worden
Ja, da hat sich jetzt geändert, ist One Password
hops genommen worden und zwar
über Okta, also ich immer denke so, okay
Okta ist auch so ein, ich verstehe nicht genau
warum Unternehmen sowas verwenden, aber okay
Ja, ist ja total super, SSO und so
muss man alles über so ein Anbieter machen
Ist Okta nicht auch hinter ZeroAuth?
Ja, auch Zero, ja.
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.
Oh ja, wir versprechen euch, es ist
gar nichts geleakt worden und es ist auch nichts
kaputt gegangen. Es sind jetzt so ein paar Dokumente
verloren gegangen.
Zugriff auf die Datenbank
oder sowas.
Ja, ich habe auch keine gute Lösung dafür.
Ich weiß nicht, wenn es das...
Ich finde es schwierig tatsächlich. Wir hatten ja letztes Jahr
schon mal 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 keepMenu, 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-Problem
hat, dann ist es 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
sein Laptop dabei hat
Zum einen, und was Backups angeht
habe ich das tatsächlich dann alles mal ausgedrückt
und in ein Bankschließfach
gelegt
Das ist keine so schlechte Idee
Weil ich halt doch fand
wenn das weg ist, habe ich echt ein gröberes Problem
Ja, also ich finde auch
für mich alleine oder so, da bin ich auch
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 freischalten und so.
Und da habe ich bisher noch keine
gute Geschichte gefunden. Ja, ich finde also
2FA tatsächlich gar nicht so schlecht.
Und dann halt immer irgendwie so ein Key mitnehmen,
wo ich halt auch, dann gibt es halt nur Timer oder so was
und einer ist dann halt im Bankschließfach
und den brauchst du halt dann.
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, sage 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 alles umstellen, 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.
Kann sein, 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 reden.
Ja, vielleicht ist irgendwas.
Mir fällt aber auch nichts ein, was man irgendwie so architektonisch hat.
Irgendeinen Tod muss man immer sterben.
Also zum Beispiel, wie teile ich auch,
hatten wir ja auch letztes Mal, glaube ich,
Geheimnisse durch Entwicklungsteams.
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,
die 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?
Ist halt auch dann wieder irgendeine Party, die da halt Zugriff drauf hat
Aber gut, dass das nichts Kritisches und so
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 Taskforce-Manager
Tja
Ja, also
Die Überleitung war jetzt ein bisschen arglich
Vielleicht reden wir ja über das Thema, dann haben wir heute nach News fertig.
Ja, genau. Und dann können wir eigentlich mal hier mit PyTest starten.
Ja, ich glaube, die meisten Menschen wissen, was PyTest ist, also das Testframework, was man oft benutzt, wenn man Tests in Python schreiben möchte.
Würde ich auch empfehlen, ehrlicherweise.
Ihr wahrscheinlich auch.
Ich auch.
Alleinig. Keine Überraschung soweit.
Aber dann überlasse ich einfach mal dem Florian vielleicht das Wort und den Einstieg in das Thema.
Das erzählst du ja vielleicht auch öfter
Also ich fand auf jeden Fall den Vortrag
den auf der Destiny Repricen darüber gehalten, das ist schon ziemlich gut
Der war spannend
Ja
Erzähl ich tatsächlich öfter, weil ich ja auch
Firmenkurse mache zu PyTest
Das wären so die Einzelfirmaschinen
die ich eben neben den OpenSource Dingen noch fahre
Und
da mache ich halt auch erstmal ein bisschen Werbung
für PyTest
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 Testframework.
Inzwischen muss man sagen, dass wirklich so das Default eigentlich PyTest ist.
Also Nose-Test ist sogar deprecated, oder?
Ne, ne.
Ah, Nose-Test.
Ja, Nose-Test.
Da habe ich mich falsch verstanden.
Da stand schon seit Jahren, steht 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 effektiv.
und wenn man sich halt dann so
anschaut, wie die Userzahlen
so ausschauen, es gibt ja, weiß ich ehrlich,
so eine Umfrage, die
Python Developer Survey
von der Python Software Foundation
und JetBrains
und da hat PyTest
ich glaube vorletztes Jahr
oder so die 50% Marke
geknackt.
Oh ja, ich hätte sogar mehr
gesagt, ehrlicherweise.
Ja, wobei irgendwie 30% halt sagen,
sie nutzen gar kein Testframework.
Okay.
Ja.
Also würdet ihr denn Tests benutzen oder wann
würdet ihr denn Tests benutzen? Das ist vielleicht auch eine spannende
Frage oder wofür. Alles
100% Covered.
Jeder Commit, der die Coverage
reduziert, wird automatisch nicht durch
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
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 Notenabschlü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% Testcoverage zu haben.
Weil ich halt finde, ja, ich berechne da irgendwie Zeugnisnoten und so, das muss halt schon irgendwie keine Box haben, idealerweise.
Also ich finde auch, so 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.
und die kritische Business-Logik.
Also jede
Einzeiler-Funktion, weiß ich jetzt nicht.
Ja, es gibt ja Leute,
die diesen Standpunkt vertreten und sagen,
naja gut, wenn man anfängt, über solche
Zahlen zu diskutieren, dann macht das eigentlich nur
100% Sinn.
Aber ich weiß auch nicht, ob das jetzt optimal ist
für alle. Also ich habe es
für ein Projekt auch gemacht, weil einfach
ich das mal machen wollte.
Ob das jetzt nötig
wäre, weiß ich nicht.
Ja, es wird schon anstrengend.
Wenn man dann externe Komponenten drin hat,
oder eine GUI-Applikation schreibt,
dann wird es schon schwierig irgendwann.
Ja genau, also welche Enden muss man dann da testen?
Also ich finde ja 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 dann schon relativ genau wissen,
was man machen will.
Und wenn man das nicht weiß,
dann braucht man halt Tests,
die man hinterher wieder wegschmeißen kann,
was die doppelt und dreifache Arbeit macht.
Aber wenn man halt irgendwie schon
ein gutes Konzept hat, dann erst Tester fü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 ineinander greifen sollen.
Ja.
Macht ihr das auch mal?
Manchmal?
Ich mache es ganz gerne bei Box.
Wenn ich halt irgendwann ein Bug-Report 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.
Genau, also ich würde auch sagen, 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 da muss ich das Feature irgendwie erstmal implementieren und erstmal sehen wie das aussieht aus User aus Code auch bevor ich da irgendwie sinnvoll Tests daf schreiben kann finde ich Klingt sehr vern w ich
ganz genauso sehen.
Also ich mache auch TDD manchmal,
aber gerade eben
auch so bei Web-Applikationen
entwickle ich oft, 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
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 mache ich doch lieber was anderes
und wenn man da zuerst
die Tests schreibt, dann schmeißt man die Tests ja mit weg
das macht ja irgendwie, ich habe dann mal
es gab auf Twitter irgendwie ein Thread, wo
dann, weiß ich nicht
Harry Percival, der auch dieses
Obey the Testing Goat
Testbuch geschrieben hat für Python
und irgendwie meinte, dass Leute noch bitte
mal TDD verwenden sollen und sich mal
im Riemen leisten sollen, dann werde ich so, ja, ich mache das mal
so. Ich weiß nicht, ich habe so das Gefühl, wenn ich zuerst Testschreiben mache, dann ist das eine totale Verschwendung,
weil man ist dann oft Sachen wieder weg. Warum sollte ich da Testschreiben
nicht wieder? Nee, nee, das ist ein Spike, das ist auch TDD, das ist schon okay.
Na gut. Ja, aber oft muss man erstmal sehen, ob irgendwas
so funktioniert, wie man denkt. Wenn man zum Beispiel die Modelle jetzt noch nicht hat von so einem Problem,
oder die man definieren muss. Manchmal muss man ja irgendwie Fixes schreiben dann erstmal, um zu
gucken, was denn überhaupt an Datenmodellen, wie die aussehen sollen und so. Oft lasse ich die Modelle
weg und schreibt gar keine Modelle,
sondern ich schreibe erstmal so,
um zu sehen, ob das in der UI funktioniert.
Das wäre dann Integration-Test?
Nö, ich schreibe da gar keine.
Wie gesagt, an der Stelle kann man noch nicht so gut Text
schreiben. Wenn ich mit Test anfangen würde,
würde ich ja mit den Tests vielleicht für das Modell anfangen oder so.
Aber wenn ich kein Modell habe, ist es halt ein bisschen...
Ja, okay.
Ich will noch kurz nochmal beim Testing-Goat
anklicken.
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 Chat-TPT meinte dann, ja,
ich hätte das designt.
Ist Quatsch.
Ist völliger Quatsch.
Das Logo gibt es nämlich schon irgendwie seit
2014 und ich bin ja erst ein Jahr später
zu PyTest dazugekommen.
Also, ja, TPT lügt bei
Python regelmäßig. Das denkt zum Beispiel auch, dass
irgendwelche anderen Menschen einen Python-Podcast machen würden,
die es nicht gehört haben. Aber hey.
Ja, ich habe
tatsächlich mal rumgegraben in
Mailing-List-Archiven und
rausgefunden, warum das so eine Panflöte
ist. Ach okay, das ist was.
Soll nämlich tatsächlich an diesem Testing
Goat als Maskottchen
auf diesem Buch anknüpfen,
weil Panflöten eben genutzt
wurden wohl, um
Ziegen zu
herden, wie sagt man denn noch
in Deutsch?
Züten, jaja.
Hm.
Ja. Ja, ich
fand das mit dem Chat-Video dann ganz witzig.
Ich hab danach nochmal so ein bisschen nachgehakt
und finden so, nö, das war nicht ich.
Und dann meint er, ja, nee, es tut mir leid,
es war Armin Ronacher.
Ach so.
Und da fand ich halt auch,
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.
Das war von Daniel Haller gemacht,
was auch nicht stimmt.
Mir sei, 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
oder manchmal mit dem GPT-
das 3.5, okay, interessant.
Ja, das ist halt, weil er sich
manchmal aus der Fantasie teilt.
Ja, gut.
Sicheres Auftreten bei vollkommener Ahnung
zu Bescheid, Jochen. Was fällt dir dazu ein?
Dass mir auf jeden Fall
die Pahnpfirte besser gefällt als
ein Schererhund als Logo für PyTest.
Ja, die Python-Feld ist super
Ja, was
haben wir denn so an Dingen, die man da
über die man mal, naja, das würde mich auch mal
interessieren, genau, du machst viele PyTest-Schulungen
geht das überhaupt?
Also ich habe irgendwie so ein bisschen, ich mache auch manchmal
Schulungen, auch so Python-Einschulungen oder halt auch
mal zu speziellen Themen
und ich habe immer so das Gefühl, ich weiß
nicht so genau, ob das
wie man da am besten
Wert irgendwie schafft
für die Leute, die darin teilnehmen, weil ich habe manchmal
und 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 Testframe 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, so ein, so ein,
wegschmeißen nochmal machen, wegschmeißen nochmal machen,
wegschmeißen nochmal machen.
Ja, aber da muss ich halt 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 sage,
das ist 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
PyTest ü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 erzählen, 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 zu
Europython da in Bilbao,
also Spanien.
Da wurde ich von
Holger Krekel, also nicht ich, aber
Holger Krekel, also so der
Vater von PyTest,
der hat halt auf der Mailing-Liste 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 Material da,
Spanien klingt auch irgendwie toll, ich war noch
nie auf irgendwie einer Python-Konferenz.
Ja, machen wir.
Dann im gleichen Jahr
noch das erste Firmentraining dann von
übernommen, weil er eh langsam aufgehört hat mit PyTest und zu anderen Projekten
übergegangen ist. Und seit da dann basierend auf
seinen Materialien das halt immer weiterentwickelt.
Das klingt gut. Also da sind auch viele interessante Sachen und ich würde auch
die einzelnen auch nochmal vielleicht kurz anschneiden, dass man so ein bisschen drüber erklärt, für die Menschen,
die das noch nicht so kennen. Wollen wir uns eine Struktur geben,
wie wir anfangen? Weiß ich 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 ich auch am Anfang nicht kannte. Das letzte, wo ich erst mich
so ein bisschen gesträubt hatte, war Hypothesis. Das habe ich dann durch deine Veranstaltung
lieber Florian nochmal eingebaut und war überrascht,
ich habe noch so ein paar Bugs angefressen.
und so. 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
einhaken, weil das Thema schon
gehabt haben und vielleicht nicht alle wissen, was
das eigentlich ist.
Da freue ich mich auch so rum bei den
Firmenkursen und oft so
und wie man das testen kann.
Prozent Coverage, also der ganze Kult ist durchgelaufen,
aber es ist trotzdem irgendwas kaputt.
Genau. Kann einem halt auch passieren, ja.
Auch schwierig,
da Prozent Coverage
gerade in einem Team sich irgendwie aufs 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, wenn man es halt nur macht, um irgendwie
irgendeinen Ast nochmal zu
durchzuwandern, ohne dass es halt irgendwas
bringt, ist halt blöd.
Aber gibt es ja sowas, wo er sagen würde,
aus eigenen Projekten, so Pi mal Daumen,
so eine Coverage ist okay?
Ich würde,
also ich weiß nicht, also meistens, wenn ich nicht drauf
achte, lande ich irgendwo so bei
ein bisschen über 80 Prozent oder sowas.
Ja, 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 die schon mal über 60, 70
meistens drüber.
Das weiß ich nicht, aber... Ja, je nachdem, wie groß das Projekt ist
natürlich.
Ja, ja. Also klar,
am Anfang hast du einfach viel mehr Gewinn, also
so ein paar Tests, die halt bei der
Web-Applikation jetzt die Views einfach nur durchgehen
und gucken, ob ein 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
ist dann 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.
Ja, am Schluss muss man sich dann auch einfach mal so die Daten dahinter anschauen und mal schauen, was habe ich denn noch nicht getestet. Da kann es eben sein, es wurde einfach vergessen, es ist irgendwie eine Fehlercondition, die es vielleicht ganz gut ist, die zu testen. Oder es kann halt sein, es ist eben ein Code, der nicht einfach testbar ist und da muss man sich überlegen, ist es davon wert.
Es gibt halt so zwei, ich würde sagen, Dinge, die es ein bisschen schwierig machen. Und zwar klar, man kann jetzt natürlich sehr viel einfacher Tests schreiben, wenn man ganz klar weiß, wie es von einer kleinen Funktion, von irgendeiner Closure irgendwie der Contract ist. Also man weiß, was reingehen, 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 nochmal testest.
Ja, nein, aber du wirst halt, dass das, was reinkommt, dann auch dem entspricht vielleicht, oder dass man halt das eng zogt. 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, 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
größere Sachen testen und dann halt nur ganz wenige
irgendwie so
End-to-End-Tests oder so
Man kann natürlich jetzt sicher auch mit sowas wie
PrayWrite oder sowas eine komplette Frontend-Integrationsstrecke
bauen, die jedes Mal dann testet, ob die Farbe
bei dem Button sich geändert hat und
ob weiße, nicht meterlinks oder rechts sind.
Aber wenn halt irgendeine Änderung von irgendeinem Designer kommt,
dann eine ganze Pipeline sieht man auseinanderfliegen,
ist wahrscheinlich eher zu viel.
So, aber
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, wo Leben dran hängt oder
was teuer ist oder sowas, dann sollte man da vielleicht ein bisschen
mehr Hörnschmalz 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 überhaupt Programme
schreibe, so ein bisschen zu überdenken,
weil man halt merkt, dass man halt so
große Module oder sowas oder Dinge, die
viel machen, dass die schwierig halt werden.
Also A, zu testen, aber es vielleicht auch eine doofe
Idee ist, wenn in einer Methode oder
in einer Funktion so super viele Sachen gleichzeitig passieren.
und solche Dinge.
Und da kommen wir halt auch wieder zu Coverage.
Wenn man halt so viel Zeugs hat,
was auf einmal passiert,
sich so von diesem Ein-Ding-für-eine-Sache-Prinzip
verabschiedet, dann wird das
halt auch relativ schwierig zu testen.
Oder überhaupt dahin zu kommen,
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.
Weil das sind so widerstreitende
Dinge und so Trade-offs.
Also ich würde ja auch zustellen,
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
hinterher die Tests sehr, sehr, 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
Also es ist halt auch so, wäre es halt schön oder elegant von der Aspektur 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 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 irgendwie buffert, reader, irgendwas sonst was API, also ich könnte mir vorstellen, dass das relativ einfach zu testen ist, aber es ist halt ein Albtraum, das zu benutzen.
und die, nehmen wir an,
Unix-File-API oder halt auch irgendwie,
keine Ahnung, Request-API in Python,
die ist halt schön, weil die ist halt
schmal und tief, aber
ich könnte mir vorstellen, dass Request 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
wenn das jetzt was ist, was nach außen geht
wo User dann halt den Schmerz
haben, dass du es einfach zu testen hast
dann muss man 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 das halt so
weil wichtiger ist an der Stelle die User Experience
also es kommt halt drauf an, denke ich
ja
ja, um auch vielleicht
nochmal bei dieser Testing Pyramid einzuhängen
ich finde
da immer so
Ich finde das ein bisschen zu kurz gedacht
Es kommt halt immer sehr darauf an, was man testet
und man soll sich halt
zu den Vor- und Nachteilen von diesen
Größen von Tests
bewusst sein, aber ich finde
zunächst, man kann immer
sagen, dass die eine Art ist besser
wie die andere Art
Wenn ich jetzt ein Command-Line-Tool
teste, bietet
es sich vielleicht an, da eher
Intuent-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 PyTest testen. Das fand ich auch ganz spannend.
Ja, das ist auch total interessant.
Sondern die beispielsweise
Waschmaschinen mit PyTest testen.
Also da
halt eine Waschmaschine haben, wo
deren Firmware drauf läuft
läuft und die
wollen sie halt testen.
Und wollen halt dazu
PyTest nutzen, weil es eben
zusammen mit Python ein relativ einfaches
und flexibles Werkzeug darstellt.
Gucken, ob noch alles geht.
Wenn man die richtigen
Hälfte drückt und das richtige Programm läuft.
Ja, und die testen 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 PyTest-Fixture, um
eine Klimakammer anzusteuern.
Die haben so eine Klimakammer
mit Elektronik drin und
sagen dann halt, über eine PyTest-Fixture
heizt mir das jetzt auf
auf 30 Grad und dann lasse ich da
meine Systemtests für
dieses Gerät laufen.
Wo auch wieder alles andere
als Python-Code getestet wird.
Ja.
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.
Und jetzt habe ich das
vergessen, was ich eigentlich sagen wollte.
Überall gibt es Fixschuss.
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 Systemtests.
oder so, End-to-End-Tests,
kann er nicht mehr wirklich einzelne
Funktionen dieses Geräts,
also im Sinne eines Unitests,
testen.
Ja, im Grunde ist das ja auch schon so,
wenn man PyTest zum Schreiben
von End-to-End-Tests, was man ja auch machen kann, verwendet,
wie zum Beispiel PyTest Playwright
oder so, dann da ist ja auch eigentlich
jeder Test im Grunde wäre weniger.
Man muss halt den Browser aufmachen,
dann da überhin und dann...
Ja.
Ja, von da
finde ich so dieses Testing Pyramid. Ich meine,
die Idee ist ja auch steinalt, um es mal zu sagen.
Bin ich
mit Vorsicht zu genießen.
Dann aber
vielleicht tatsächlich dazu, du fixtures und
was fixtures sind und wie man die baut oder
macht ihr das mit
Factories oder macht ihr das ohne Factories
oder sind Factories doof oder
gibt es da so verschiedene Sachen und
was sind überhaupt fixtures 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 dir ein einfaches Beispiel.
Also wenn wir mit einem normalen Webclient
zum Beispiel arbeiten würden, dann würde hier halt eine Fiktion
der User und ein Client und dann guckt man, wie das
interagiert.
Ja, am Schluss ist
eine Fixture
im Prinzip einfach eine Funktion, die
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 Config-Klasse.
Oder in den Trainings habe ich das Beispiel von so einem
R-Pan Calculator, den ich testen will.
Der nimmt dann auch eine Config als Argument
und sowas. Und damit ich
einfach nur die Instanzierung
von diesem R-Pan Calculator,
also einfach ein 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 in echt auch gerne hätte,
um die dann in dem Test benutzen zu können,
zu gucken, ob die Ergebnisse, die man erwartet,
dem entsprechen, was man möchte.
Genau.
Ja, schwierig, das jetzt so in paar
Sätze zu fassen. Ja, ich finde das auch sehr
abstrakt halt. Also wenn man das in Probe sieht, dann wird das
relativ klar. Die Spezialität bei
PyTest Fixers ist halt, dass die so
diese magische
Dependency Injection gibt, sodass man halt
einfach nur den Namen der Fix
in die Parameter
vom Test schreibt und dann
das automatisch ausgeführt wird.
Genau, dafür schreibt man die Funktion ja quasi in den ConvTest einfach rein.
Ja, nö, musst du nicht.
Ja, 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 ja auch Support in der IDE,
dass man draufklicken kann und landet dann da.
Also bei PyCharm geht das zum Beispiel, dass man
halt auf einfach eine
Fixture in PyTest klickt und dann halt
im 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
auf deiner Wahl.
Es ist schon eigenartig, ja.
Also ich sag so, dass
inzwischen hab ich's glaube ich raus, wie ich das
den Leuten erkläre, dass das passt.
Aber gerade am Anfang mit
den Trainings war das so der Punkt, wo ich
sagen musste, ja, ich werde auch jetzt
erstmal verwirren und irgendwann werde ich es
verstehen, aber nicht gerade vom ersten Satz.
Ja, ich fand das auch sehr, sehr schwierig, also
vor allem 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 dieses Setup und Teardown
vorher und nachher macht und eigentlich nicht
First Returns und Airbus Yielded und dann was da so passiert, das war schwer zu verstehen.
Also auch, dass die Fixtures alle immer neu gebaut werden, dann
für jeden Test, Atomar 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 Teardown und so, das kommt ja dann erst mal
obendrauf auf das Grundkonzept. Ja, ja. Also um Fixtures an sich
erst mal 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 viel komplexe Tests darzuschreiben
und vielleicht erstmal ein klein oder ein, zwei kleine
und halt einfache Objekte einzugeben,
wo man halt guckt, wie die
zusammenhängen zum Beispiel oder was die tun.
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 Florian auch gut gezeigt hat,
Parametrisierung mit beispielsweise
Data Clusters oder sowas,
dass man halt tatsächlich eine
Plethora, 100 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 noch reißt.
Ohne jetzt direkt auf Hypothesis zu gehen,
Hypothesis testet nochmal, also mit
zufälligen Fixtures, wenn ich das richtig verstehe,
oder Zufallswerten für
Dinge in den Fixtures.
Ja, vielleicht noch kurz zur
Parametrisierung. Wenn ich mir
jetzt Python 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-Funktionen.
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.
Oder hast du auch eine Seite übrigens,
kurzer Exkurs, fstring irgendwie
Docs, kann das sein?
fstring.help, genau.
Oh ja, die habe ich auch schon oft.
Ja, ein guter Punkt.
Eine Webseite von mir.
Habe ich mal irgendwo an der PyCon
Germany, ich wollte es schon seit Jahren
machen und dann kamen da die Lightning Talks
unter PyCon Germany und dann
ab und vor den Lightning Talks, habe ich die noch kurz
gemacht, um sie dann
eben da vorstellen zu können.
Ja, aber das ist echt super, weil sowas hat echt gefehlt,
das ist echt gut.
Hör ich gerne.
Ja, Parameterization
macht es einem eben einfach,
um dann aus einer Testfunktion, die nur
ein Wert testet,
den so zu erweitern, um zum Beispiel
10 oder 20 Werte zu
testen, ohne 10 oder
120 separate Funktionen daf schreiben zu m Und das ist sowas das vermisse ich dann sehr schnell in anderen Testframeworks meistens geht das schon irgendwie aber halt mit einer aufwendigeren Syntax als in Python oder als mit PyTest
Ja
genau, also PyTest Parameterize
ist halt irgendwie dann der Dekorator, den man
da verwendet, den benutze ich auch ständig
aber es gibt auch noch
eine 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 auf mehrfach
ausgeführt mit den unterschiedlichen Parametern.
Du meinst, wenn du mehrfach hintereinander yieldest, weil das mit dem ersten Aufbruch
mal zweiten Aufbruch, dritten Aufbruch passiert?
Nee, ich weiß es gar nicht mehr genau.
Nee, du kannst
im Fixture Decorator
kannst du dann nochmal eine Liste von Params
angeben.
Und dann wird jeder Test, der die Fixture nutzt,
wird halt mehrmals ausgeführt.
Genau, genau.
Wenn du irgendwie mehrere Backends hast
oder mehrere Implementationen, die sich
Ja, das ist halt ganz nützlich,
gerade für das Teardown. 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 zugesehen,
wie man das ordentlich
machen soll, irgendwie.
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 einzelne Dinge von Faker vielleicht,
um sich Zufallssachen auch
erstellen zu lassen.
Ja, denke ich, ist aber ein anderes Problem.
Und dann baut halt dann diese
Funktion halt dann zufällig Objekte zusammen
und dann könnte man 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,
das Ergebnis immer gleich,
ob man einen Spezialfall, wo es nicht passt,
hat man einen 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, wäre jetzt auch eine Hypothesis,
was wir sicherlich noch
sprechen.
Also Jochen, soll ich auch kurz gestören?
Ja, ich habe so etwas
Factory Boy und sowas früher mal verwendet,
aber ich mache das eigentlich inzwischen nicht mehr.
Ich habe...
Mach doch kurz fertig.
Ja, 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
Python...
Und ich weiß gar nicht, 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 mal die bessere Variante
und ich habe auch oft jetzt in Projekten
inzwischen sowas wie so ein
DevData-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 dieses, also
meine Applikation mal in diesen Zustand, wenn 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-Buy und sowas gar nicht mehr.
Ich habe gerade den Blog-Artikel gefunden, den ich meinte.
Hast du den von Luke Plant? Luke Plant, genau. Ja, okay. Ja, der ist gut.
Ja, und so ähnlich habe ich das auch dann, glaube ich, versucht umzubauen.
Ja, 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...
Ja, und Faker ist halt nochmal eine andere
Geschichte, wo es einfach darum geht, dass man halt
wenn man jetzt, dass man sich nicht als Faker
selber ausdenken muss, dass man so plausible Daten hat
Okay, ja
Du kannst Faker auch in Seed mitgeben zum Beispiel
Ja, und dann kannst du halt
Genau
Ja, genau
Ja, vielleicht
wäre das jetzt gerade der Punkt, um noch was zur Hypothesis
zu sagen
Klingt gut
Das ist ein Projekt, was erstmal nicht viel mit PyTest
zu tun hat, aber sich halt doch
gut in PyTest integriert
zu sogenannten
Property-Based Testing.
Man kann sich das so ein bisschen wie
ein Fuzzer vorstellen, was also
Zufallsdaten generiert.
Ja, man kann mir zwar sagen, gib mir irgendeinen
Integer und dann nimmt der
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
werden eh schwierig.
Also Herr Patos, das kann auch sehr langsam werden
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 Invariants
zu testen, also Dinge, die immer wahr sein
sollen, egal was der Input ist
Also wenn man irgendwo so
ein Compress und ein Decompress hat,
dann kann man das einmal durchlassen, einmal sagen
Compress, einmal Decompress
und dann soll das gleiche wieder rauskommen
Decrypt, Encrypt
Encode, Decode, alles so diese
Paare, die sich halt umkehren
sollten
Ja, da merkt man ja relativ schnell, ob man
irgendeinen Hex halt wo, ups
Genau, dann lässt man das mal laufen
und dann ist die Chance
relativ groß, dass Hypothesis halt
mit irgendeinem komischen Corner Case kommt
den man echt nicht bedacht hatte
Ja, das ist mir auch
schon öfters auf die Füße gefallen, hat mir dann
die Augen geöffnet, warum zwischendurch irgendwas
komisches passierte, was man irgendwie nicht erwartet hätte
Muss man doch mal drüber nachdenken, was mache ich denn da überhaupt eigentlich
Wenn was kaputt ist, ist das schon immer so ein bisschen
Ja, ich glaube, das muss ich mir mal
Ich habe das schon mal ausprobiert, aber ich habe es noch nicht wirklich häufig in den Dingen 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 aufzeichnen, glaube ich.
Ja, die Idee davon ist eigentlich, dass es eben nicht langsam ist, dass man es halt als Teil seinen normalen Tests laufen lassen kann.
Aber für mich war das immer so ein Punkt, wo ich dann angefangen habe, tatsächlich die Sachen einzuschränken.
einzuschränken. Also wenn ich halt gemerkt habe, okay,
das 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
X-Cases gefunden, die ich rausschmeißen konnte und konnte
dann mir sinnvoll überlegen, okay,
der Eingabewert ist jetzt vielleicht doch nur maximal
siebenstellig oder so
und nicht noch mehr. Und dann wurde
der Test natürlich dann viel schneller und dann habe ich
gesagt, sorry, aber mehr ist jetzt hier einfach nicht
erlaubt und das hat direkt
mit abgefangen. Und so,
Das war, glaube ich, an der Stelle eine gute Strategie, um mal so ein bisschen die Grenzen zu gucken, was überhaupt an I.O. da sinnvoll ist auch.
Sondern so eine Sanitization zu machen an Teilstellen oder sowas Gutes.
Ja, 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 auch trotzdem nur idealerweise in Bruchteilen eine Sekunde geht.
Das ist nicht immer der Fall.
Ja.
Ja, das ist auch so ein interessantes Thema, finde ich.
und PyTest.
der Testmarker.
Man könnte ja
Dinge, 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 davon, wie viele Tests
man da hat.
Also wenn ich mir jetzt PyTest selbst anschaue,
wenn ich mir QBrowser anschaue, dann ist
das irgendwas Vierstelliges
und dann wird es
und wie man das testen kann.
gesehen, dass das jemand erfolgreich gemacht hat und
dass es in einem größeren Projekt dann wirklich gut funktioniert hat,
weil, ja, das könnte
ein Weg sein.
Ja, ich bin jetzt nicht so
viel im Web-Umfeld
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 Fulltext-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
Tester dann überhaupt nicht mehr das testen,
was eigentlich in der Realität läuft.
Ja, klar. Das ist das Problem.
Ja.
Ja, ich finde
das auch schwierig. Also so Datenbank-Sachen testen,
muss man sich oft darauf verlassen, dass das irgendwie
geht und dass das 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, ne, 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 Datenbank
laufen zu lassen auf einem Dev-Rechner ist manchmal
schon eine Herausforderung, je nachdem, was man
alles aufhaben muss.
und... Ja gut, muss ja,
dann glaubst du halt angucken können auf dem Testsystem,
was die Daten auch schon für... Ja, aber
wenn dann halt Menschen drei oder vier oder fünf
verschiedene Projekte gleich machen müssen,
und dann haben die nur irgendwie einen Rechner mit 80 Gramm
oder sowas, müssen dann irgendwie aber 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 Datenmarken schon bumm, dann musst du dann irgendwie gucken, dass
du vielleicht eine hast, die dann irgendwie weg abstrahiert,
wo dann aber auch die Klientel stimmen, und dann musst du, wenn du eine abreißt,
nicht alle abreißen, weil du den Container nicht einfach kaputt machen kannst,
die Volumens und dieses was, und ja.
Ja.
Wir werden schnell schon wieder mit dem Kopf gegen die Wand
Softwareentwicklung
mit 8 GB RAM
finde ich halt auch so ein bisschen kritisch
Ja, ist eine Katastrophe, muss ich sowas nicht tun
Also, Apple
macht das ja, dass sie ihre neuen
MacBook Pros haben, im Standardmodell
mit 8 GB
für 1000 noch was Euro
Ja, das ist eine Gemeinheit, aber ja
Aber ja, ich meine, ich mit
Qt-Browser, vielleicht soll ich da ja dann auch
und wollen noch ein paar Worte dazu sagen.
Da muss ich halt ab und zu
auch Chromium kompilieren, also
der Code hinter Google Chrome.
Und
das braucht so mit einem
Developer-Build, also mit Debug-Symbolen
und so, braucht das halt mal so
irgendwie um die 30 GB RAM.
Wow, allein das Kompilieren von dem...
Okay, das...
Wenn ich es halt parallel machen würde,
nur mit so einem Build-Job würde es mir wahrscheinlich
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 den 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 auch so ist.
Da habe ich echt irgendwann ein Problem.
Ja
und schauen dann halt mal, was da zurückkommt von GitHub Actions.
Dieser Test ist fehlgeschlagen.
Oh, ja okay, meistens nicht.
Manchmal gelingt es einem halt, das durchzukriegen, aber ja, ja okay.
Was auch super ist, wenn man dann gar keine Testumgebung hat und das halt direkt durchgeht.
Da war es halt auch keine Entwicklungsumgebung.
Was ist das da, Codespaces oder so?
und dann ist alles nur noch
der Cloud. Wunderbar.
Jemand anderes Problem.
Jetzt lasse ich dann halt so
die Tests für das, was ich gerade daran arbeite,
die lasse ich lokal laufen. Aber so eine volle
Testbatterie soll
woanders laufen.
Auch das ist vielleicht ein guter Punkt für
Marx. Also um Tests zu markieren
nach verschiedenen Themen oder sowas, dann kann man
halt nur Tests laufen lassen für das eine
Topic.
Wenn du entwickelt hast, machst du das ja meistens.
und Python ist ein Test, das du einfach sozusagen, entweder nur den einen Test, von dem du weißt, dass der halt betroffen ist, irgendwie laufen lässt oder halt eine Gruppe von Tests, die da außenrum sind.
Ja genau, aber genau, die Frage ist halt diese Gruppe, weil wenn du die thematisch gruppierst 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 den einen Testfahrzeichen schreibt oder an die Applikationen, an die ganzen Apps, wo die zugehören oder so.
Ja.
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 auch da eine Frage, kann man sich über die Architektur
Gedanken machen, gibt es vielleicht doch Gründe, das dann so zu machen?
Und mit diesen Markern, die man da bei PyTest
drüber setzen kann, dann kann man die 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, wie ich es projektübergreifend in Tests sage, die nutzen irgendwelche GUI-Dinge
und testen einfach nur Python-Code.
aber ansonsten, ja
ich kann mir jetzt vorstellen, so bei einem
Enterprise-Projekt, können 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 ein Multilead voneinander
Ich weiß nicht, also bei mir reicht auch
die 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 Teste in einem Tests-Directory
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
Tests-Verzeichnis zu haben.
Ich mache tatsächlich beides.
Also ich habe einen Testverzeichnis, wo
so die grundlegenden Sachen drin sind, wie
Kernfunktionalität, die Clients,
für Authentication, die Nutzer
und sowas.
Und der Testwarner und diese ganzen Sachen
und die Hauptfixers.
Auch witzig, manchmal auch
meist in anderen Fixers schon. Das heißt,
Fixers 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 Dango oder so.
Da muss man die halt importieren, einfach in den Comptest, 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
Module arbeiten und die Leute wissen halt direkt, dass die
Tests da dazugehören und man vergisst dann
nicht, welche für welche Module, man kann halt auch immer 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, sind Tests auch sehr nützlich, so was
als wie 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 der gut
geschrieben ist, sagt der Test, Test ist ja die Logik,
was da passieren sollte und dann lese ich
den 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 Bug
in einem Python-Projekt finde, der sich nutzt
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
ein bisschen an, um mehr ein Gefühl
zu kriegen, was da passiert
wenn es dann welche gibt
Ja, gut
Ja, das ist tatsächlich auch eine der Sachen, die
oft runterfällt, ne?
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
Python-Package gespiegelt.
PyTest-Dokumentation
ist auch noch so eine, ich fand
PyTest-Dokumentation war eine der schwierigeren Dokumentationen,
die ich lesen durfte.
Im Laufe der,
wenn er so Python kriegt.
Ja gut, das ist halt auch kompliziert.
Ja, aber ich habe da
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, das nochmal so in den Augen eines Neulings anzuschauen.
einfach, also dass man wirklich einfach verstehen kann, was denn da passiert, das ist so eine
hohe Kunst, glaube ich.
Und das war also bei PyTest, ich muss auch sagen, mittlerweile ist es einfacher, also
die Doku zu lesen, aber manchmal ist es, hä, was wollen die denn jetzt und warum?
Und dann waren auch so ganz viele Fragen offen, die haben dann 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
was steil.
Aber ja, also
noch vielleicht so eine coole Funktionalität
von Python, ich glaube, es gibt noch jede Menge Plugins,
die wir noch vielleicht erwähnen können.
Ich würde eins gerne herausnehmen, VCR,
also irgendwie so Video Recalling auch noch,
das ist auch sehr cool, ja.
Was macht das denn?
VCR stellt quasi,
wenn du jetzt eine API nutzt, zum Beispiel
ein 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 nimmt es einfach die
und tut halt so, als wäre die echte API-Antwort
quasi in der File drin und dann hast
du quasi die echte API-Antwort gemockt,
quasi genauso, wie sie kommt und du kannst
halt PyTest 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,
und wie das funktioniert.
Ja, ich weiß nicht, aber...
und wie man das dann auch in Python verändern kann.
einfach PyTest 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 könnte man natürlich machen, ja.
Dann je nach API halt sagen,
das können wir nach Avnecia irgendwie
wöchentlich oder monatlich oder sowas mal
ausführen. Ja, also ich finde
es super spannend, also das macht 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.
Man kann das sogar
abusen. Wenn man
sich viele
Zeugs abspeichern will von
irgendwelchen Scrapern oder sowas, könnte man das tatsächlich
einfach einsetzen, um sich die
API-Calls einfach mal wegzushaken
und das relativ easy.
Ja, ich weiß nicht.
Also genau,
ich überlege gerade, was ich
an Plugins normalerweise verwende.
X-Test verwende ich
tatsächlich irgendwie. Aber
das muss man ja, wenn man irgendwie Testparallel
ausf lassen m Bekommt aber noch viel mehr Zeug 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 PyTestMock zum Beispiel,
finde ich super.
Immer wenn ich Unitest-Geschichten irgendwo mache
und dann türmen sich so die
Patch-Dekoratoren oder ganz
viele Context-Manager und dann ist PyTestMock
echt total, also sehr angenehm.
Was macht das?
Das übernimmt,
es macht das halt automatisch. Du kriegst halt
Mocker, schreibst als Fixer
sozusagen in deinen Test und dann
rufst du halt Mocker.patch
irgendwie einfach auf, musst aber
da nicht den Context Manager drum rum machen
oder irgendwie das Insta-Kurator verwenden
und kannst das halt auch mehrfach aufrufen,
ohne dass du da halt irgendwie dann eine
Verschachtelung von Context Managern hast
und das wird halt hinterher auch wieder
alles entmockt sozusagen,
ent-gepatcht,
wenn der Test vorbei ist und so.
Ja, du hast recht,
das ist für viele Sachen ganz nett, aber ich finde es auch irgendwie
und Python
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.
Apropos schöner Output, PyTest-Witch natürlich.
Ah, okay, ja.
Ja, das hier überhaupt,
das hat man noch gar nicht so richtig,
das ist eigentlich fast das Hauptfeature
von PyTest für mich jedenfalls,
dass man einfach so
Assertion schreiben kann und das halt funktioniert
und man halt trotzdem eine sehr schöne Ausgabe
kriegt, die einem zeigt, wo ist
genau was unterschiedlich und so.
Das ist halt sehr, sehr angenehm.
Nicht so komisch als Asserts, ich will den
Camel Case.
Das ist aber auch
übrigens eine ordentliche Portion
Magie. Ja, ich fürchte auch irgendwie, ja.
Weil an sich
dieses Assert Keyword von Python,
das macht einfach nur einen Assertion
Error, also ohne jetzt, dass man
irgendwie Zugriff hat auf Infos, was
da passiert ist.
PyTest macht da eben
sein Rewriting.
Ja, durch den Dekorator.
Das ist den Abstract
Syntax Tree, was
Python als so ein Modul generiert,
intern, bevor das wirklich dann zu
Python Bytecode wird.
Passiert das beim Import der Testmodule
irgendwie, da wird der Bytecode dann
gedruckt?
Nicht der Bytecode, sondern halt
ein Level vorher, der 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
Aber es sind viele Dinge
Wo ich sagen muss
Es ist sehr viel Magie
Aber irgendwie so unterm Strich auch sehr angenehm
Also hat sich irgendwo
Bewehrt
Entspricht diesem Pythonic ästhetischen Ansatz
Irgendwie das in klarer Sprache
hinzuschreiben, was das machen soll.
Das Assert ist da für Tests, glaube ich.
Sieht einfach schick aus.
Ja, aber wäre das jetzt nicht auch schick,
wenn Assert in anderen Stellen
genauso funktionieren würde?
Vielleicht denken ja Leute, wenn sie das in PyTest
verwendet haben, ah, das funktioniert ja immer so
und machen das dann irgendwann anders.
Dann verhält sich das plötzlich ganz anders, als sie gedacht haben.
Ja, aber man kann ja zwar Asserts
ausschalten, wenn man das richtig
aufruft in Interpreter, aber normalerweise
macht man das ja nicht. Normalerweise fährt Assert dann einfach
mit einem Assertion Error auf die Nase.
Ja, ja, aber in PyTest sieht das dann wieder anders aus.
Naja, aber das ist eigentlich relativ klar, oder?
Dass halt, wenn ein Test fällt, dass da eine Assertion Error dann mit mehr Informationen auch zurückgegeben wird.
Also, das macht der schon.
Also, der im Prinzip ein fehlender Python-Test heißt, du hast eine Assertion Error.
Nee, nee, nee.
Ja, aber ein Python-Test macht dann halt eine Menge Dinge.
Ja, gut, aber dafür ist ja das Framework ja da.
Ich glaube, dass das...
Ja, da wollte Ronny Pfandschmid, auch einer der Maintainer,
wollte da auch mal irgendeinen Pip schreiben oder sowas,
dass man sich eben bei Python
gerade schön da reinhängen kann
in diese Assertions.
Ja, das wäre
schon ganz nützlich.
Für irgendwie so eine Assertion-Lib oder sowas, die man einfach importiert
und dann hat man schön noch Assertions oder so, das wäre doch cool.
Aber ja, wahrscheinlich ist es nicht so.
Genau, aber ich glaube, da ist es leider nie was geworden.
Was es gibt für Notebooks
vielleicht noch ganz interessant,
ein Ding namens IPyTest,
was eben PyTest
in diese Notebooks integriert.
Man kann einfach mit Prozent-Prozent
IPyTest, kann man halt PyTest ausführen
und hat dann auch Zugriff
gleich auf die lokalen Variablen
aus dem Notebook und sowas.
Und das ist, wenn man das einmal einrichtet
in einem Notebook, dann kriegt man
auch in diesem Notebook global
quasi geschenkt
die Assertion-Infos,
wenn eine Assertion fehlschlägt.
Ach, das geht dann auch an anderen Stellen?
Genau, das
hängt sich dann halt da irgendwie ein.
Ach cool, das kann ich auch noch nicht
Ja
Noch mehr Plugins hier benutzt?
Äh
Finde ich nochmal Freescan, wenn ich irgendwie so
Zeit sagen will, auch zu der und der Zeit
oder die Zeit muss ich jetzt um zwei Stunden verschieben
zwischen zwei Tests oder sowas, das ist ganz nett
mit Context Manager 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 Request aufruft, ruft man halt erstmal
Responses auf und das mockt einem das weg.
Ich glaube, das gibt 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 sowas wie
FreezeGang, VCR,
Responses oder diesen HTTPX-Mock.
Ich bin eigentlich der Meinung,
jede Python-Library,
die irgendwas macht mit externen
Systemen, also sowas wie PySerial
beispielsweise, sollte
halt gerade auch irgendwie so
Testsupport oder so Mocs gleich mitliefern
und danach schöne, maintained
getestete Mocs.
Mocking ist immer noch sowas, das macht man
irgendwie so ad hoc in jeder Testsuite
wieder neu das Rad erfunden.
Ja, das ist natürlich auch so.
Das stimmt, da ist relativ viel Zeit immer
bis man das richtig läuft.
Das ist wahrscheinlich sogar der Hauptteil, den man braucht
für Testschreiben.
Nö, das würde ich jetzt auch nicht sagen.
Aber es ist halt immer wieder
das.
Also 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
dann werkeln, weil man einfach nur
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 drauf, aber ich nutze noch PyTest
Rerun Failures
wo man Tests halt aus Flaky markieren kann
und wenn sie fehlschlagen, werden sie halt nochmal
ausgeführt
weil ich bei Qt Browser
halt wirklich eine Squee Applikation
mit so vielen externen Komponenten
dieses Problem
mit Flaky Tests fast nicht in den Griff kriege
und dann bis zu irgendwie
eine Assertion Failure in der Libc
also die Library C
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 ja ganz mies, wenn irgendwie so ein Test
nur jedes hundertste oder so
Mal fällschlägt, das ist ja ganz eklig
Irgendwie so
das rauszufinden
Das ist immer
Ist das ein Plugin oder kann das Python testen?
Das weiß ich gar nicht, aber dass man die Reihenfolge
irgendwie zufällig macht
Randomize oder irgendwie so
Ja, da gibt es ein paar
Randomly
gibt es.
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 nochmal geträumt werden?
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 irgendwie
bei 30 Grad laufen
sollen, dass man die erstmal laufen lassen will,
anstatt jedes Mal auf minus 10 Grad
runter zu kühlen und wieder hoch auf 30.
Oder wie auch immer.
Macht auch keinen Sinn.
Ja.
Ja, PyTest
BDD nutze ich noch. Ah, okay,
das ist interessant. Ja, da habe ich auch schon häufiger was
gehört. Ja,
ich habe es auch mal versucht zu nutzen.
Also, vielleicht noch mal kurz, der
Behavior Driven Development
Test, glaube ich auch.
Man kann so Logik, so Business Logik
schreiben, so für den PO oder so
und der kann dann so Sätze
formulieren in seiner eigenen
Sprache und dann guckt Python
BDD, ob es geht oder nicht.
Aber so tief rein. Das ist im Prinzip einfach noch mal
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 auf 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.
Genau.
Also ich habe es wieder rausgeschmissen, ich habe es ausprobiert, aber irgendwie, wahrscheinlich lag es aber auch an dem 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-End-Tests für Cube Browser.
Jetzt müsste ich da vielleicht nochmal kurz einhaken, was Cube Browser 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.
Darüber bin ich danach zu PyTest gekommen.
Und das hat
dann so ein Interface
mit einer Commandline
quasi eingebaut.
Und da habe ich dann auch viele
End-to-End-Tests, wo ich halt einfach irgendwo
ein Kommando hinschicke zu einem laufenden
Browser und dann
erstmal schaue mit einem Web-Server,
der direkt im PyTest-Prozess läuft,
wurde dann
die und die Seite aufgerufen
oder ist das und das passiert.
Und so diese End-to-End-Tests
habe ich dann halt eben mit dem PyTest-BDD
geschrieben, dass ich sage,
when I run open
und irgendwie
then this and that page
should be loaded.
Ja, an der Stelle klingt das durchaus sinnvoll, weil wahrscheinlich hat man dann ganz viele davon und da will man ja wahrscheinlich dann nicht immer das ganze Boilerplate einschreiben
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 ist ein bisschen das Problem mit flaky 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 da neue Leute
dazukommen, die noch nie was mit PyTest gemacht
haben, dass du denen sagen kannst
guck, schreib 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
An der Stelle ist es vielleicht auch noch ganz interessant, genau, das ist ja
auch, selbst wenn man jetzt nicht BDD
Test 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
einen 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
Sinn, Tests immer so zu strukturieren,
dass man halt auch, wenn man jetzt auf den Test guckt,
sofort weiß, okay, ach, an der Stelle
wird nur irgendwas zusammengebaut, an der Stelle wird jetzt
der eigentliche Aufruf gemacht und hier, es hatten wir irgendwelche
Dinge, wo wir dachten,
das müsste jetzt da rauskommen.
Das BTD, das klingt
auch so ein bisschen nach, als könnte man das mit Playwright
machen. Ich weiß nicht, ob das dieses Pattern auch ist.
Wie mein Jochen?
Die Playwright-Tests, die ich
bisher gemacht habe, ne, die waren halt einfach
da habe ich das alles immer von Hand hingeschrieben.
Ja.
Es ist halt, ja, das 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 erwarte
das. Ja, aber es sind schon einfach
Funktionsaufrufe, es ist nicht irgendwie Text,
den man hinschreibt. Ja, okay, stimmt.
Ich mache es halt anders, ich soll direkt abheißen, ja.
Ja.
Ja, ich glaube, mir fällt kein Plugin mehr ein, was ich jetzt empfehlen wollen würde.
Welche hatten wir ja schon.
Da muss ich mich fragen, ob es sowas gibt.
Ich weiß nicht, in der JavaScript-Welt, das sehe ich halt ab und zu mal,
gibt es halt auch so Dinge, da läuft halt einfach immer irgendwie,
oder da wird halt geguckt, ob sich irgendwas an den Files geändert hat.
Und dann läuft halt da irgendwie der Testrunner quasi die ganze Zeit
und alle Tests, die dann halt sozusagen davon beeinflusst sein könnten,
von irgendeiner Änderung, werden dann halt nochmal ausgeführt.
und es gibt dann so eine Art Dashboard, was halt
gerade nicht funktioniert oder was funktioniert.
Gibt es das für PyTest eigentlich auch?
Weil ich glaube, sowas habe ich noch nicht gesehen.
Ja, es gibt Testmon.
Ah, okay.
Cool.
Ein größeres Projekt, testmon.org
hatte ich mir mal
angeschaut, aber jetzt auch schon länger nicht mehr.
Oh.
Dann paniken 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 jetzt nicht
so in fix fertig
jetzt eben außer Testmon
es gibt schon in fix fertig, aber jetzt 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
naja, 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 wirklichen 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
müsst ihr wahrscheinlich mal noch schauen, dass ich das
auf die PyTest-Webseite auch mache, weil bisher war die Resonanz
nicht so viel
ich
Ich habe da halt mal von einem Kunden von mir das Angebot bekommen, dass die uns da hosten, weiß ich, in Vorarlberg, was erstmal so im Nirgendwo ist.
Vorarlberg?
In einem Städtchen da mit Tiefenalpen 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 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 da eigentlich ganz gerne
ein paar mehr Leute noch haben
Also 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üsste man sich alles im Detail
mal 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 Sommer?
Genau im Juni.
Wir haben zwei Wochen.
Mitte, Ende Juni
müssen wir noch schauen, welche Woche
das wird.
Dann wäre eben
die Hoffnung, dass
wir da Leute zusammenkriegen,
die irgendwas machen wollen. Ohne eine fixe
Idee zu haben, was genau,
es kommt dann mal alles noch.
Aber halt einfach so ein Development Sprint
wieder mal zu haben und sich mal wieder in Person zu sehen.
Gute Sache.
Das ist mal super sowas.
Ja, was gibt's noch?
Ich würde sagen, mit PyTest
sind wir, glaube ich, mit den Themen, die
ich zumindest auf der Liste hatte, soweit
Dann können wir vielleicht zu den Pics
der Woche des
Monats der Folge übergehen
Ja, können wir gerne machen
Was kann man richtig mal? Kapitelmarker?
Pics? Upsi
Also ich
picke fstring.help
Aha, für mich geehrt
Ich glaube, ich hatte
und PyTest.
aber die 22 ist auf jeden Fall, ich glaube, die habe ich,
das Ding ist echt...
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 Enrico Capazzi
ein Fast AI.
Ja. Würde ich sagen, dass dann ist
mein Datasign 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 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 auswählen, welches Modell hätte man gerne.
und das, wenn man das benutzt,
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, es 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 sich jemand 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, es ist halt hauptsächlich
TypeScript und WebAssembly
Du meinst aber nicht MoneyML
MoneyML
Ne, 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 MoneyML
Weil da muss ich mal grad nachgucken
ob das
genau so
heißt
Das heißt einfach nur
LLM Visualization
und bbcroft.net
Also was man mit MoneyMill
kann man quasi seine eigenen Sachen aufbauen.
Da kann man sich auswählen, welche Layer man
in sein Neural-Network reinsteckt und dann
sowas bauen. Oh, das
sieht aber auch schick aus.
Ja, kann man jetzt nicht sehen, wenn man es nur hört.
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.
Ja, dann machst du MoneyMill direkt
noch dazu, dann haben wir beide.
Okay, mach ich das auch.
Ja.
Florian, hast du auch einen Pick?
Ja, ich hatte
erstmal gar nichts und jetzt sind mir da gleich zwei Dinge
eingefallen.
Zum einen, als du
Data Visualization erwähnt hattest,
eine Webseite, die ich
letztens von
einem Kollegen gekriegt habe,
datatowiz.com,
was einem so durchleitet, wenn ich
mehr Regeln dazu, das irgendwie
um sein dann
unmöglich zu machen.
Und basierend darauf
Das Passwort
gehen wir nicht auch.
Und basierend darauf hat jemand halt
The Evol Game gemacht, wo man eine Python
Expression eingeben muss, die dann immer
mehr und mehr Regeln folgen.
Okay, interessant.
Das klingt gut.
The digits in your password
must add up to 25.
Großartig
Sehr gute Idee
Ganz so ähnlich sieht es nach meinem EvoGame aus
Ja, ne, vielen Dank
Das klingt doch super
Ja
Ja, ich glaube, dann sind wir
Ich glaube, dann sind wir durch
Wie, da warst du da, Florian?
Ich fand es sehr schön
Ja, danke euch
Viele Dinge, die ich noch nicht wusste
Ja, Python ist ein ganz essentieller
Teil, glaube ich, von dem, was wir so machen.
Auf jeden Fall.
Ja, dann danke, Florian. Bleibt uns
alle gewogen. Danke, Jochen.
Schreibt einen, wenn ihr noch was wissen
wollt, Fragen habt, Anregungen, Kommentare.
Vielen Dank auch für unsere lieben Hörerinnen und Hörer,
die uns Fanpost schicken oder
Fragen stellen und so. Das ist immer sehr nett.
Hallo at PythonPodcast.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 Himini, echt? Ist das schon so lang
Ja
Jetzt fühle ich mich ja noch älter als ich normalerweise schon fühle
Heißt also, die Folge muss jetzt
noch dieses Jahr rauskommen
Das wird aber auch noch
Weiter abkommen
Ja, schauen wir mal
Also
Vielen Dank für eure Aufmerksamkeit
Ja, ebenso
Tschüss