Transcript: PyTest

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

Hi Jochen.

Ja, hallo Dominik, willkommen.

Ja, mein Gast dabei, und zwar den Florian. Hey Florian.

Hallo.

Ja, hallo zusammen.

Ja, wir haben gehört, du machst ja öfter mal was mit PyTest und dann 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 wahrscheinlich 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.

Da kann ich vielleicht später noch mal mehr dazu sagen.

Über das Projekt bin ich danach zu PyTest gekommen.

Und was ich jetzt eigentlich mache,

Zum einen, ich arbeite an QBrowser

und PyTest, 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,

ganz viel auch Freiheit,

sag ich mal, wann ich was mache

und eben auch viel PyTest.

Ja genau, du bist einer der PyTest-Maintainer

auch, ne?

Genau. Das hat auch ganz lustig

schon angefangen. Ich habe

da halt eben durch Cube 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.

So was.

Also doch schon eine Weile her.

Also 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-Seite,

da habe ich sie eben.

Ja, cool.

Ja, das klingt gut.

Über die ganzen Sachen 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 dann immer alles umstellen, was mit Django im Einsatz und ja, war aber diesmal sehr entspanntes Update, hat alles gut funktioniert.

Ging gut, nicht wie Deprecated.

Ne, also 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, nämlich da ging es darum, dass er eigentlich blöd ist, wenn man bei einem Modelfield 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 Bulk Create und man kann

halt auf verschlungenen Wegen

irgendwie Dinge erzeugen in der Datenbank. Bulk 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

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-Antrag zugeschrieben, vielleicht kennst du den auch.

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

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 war

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 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.

Ja, dann genau

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...

Ein Suchindex. Ja, 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 auseinanderproben.

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

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

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

Ich weiß nicht genau, ob euch das irgendwie tangiert

oder ob ihr das mitbekommen habt, ob ich das nur mitbekommen habe,

weil ich das halt zufällig irgendwie alle immer verfolge.

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

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

Im Management, ja. Ich bin hier, ich bin doch nicht hier, ich bin wieder da, hurra.

Genau, und ja, 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 ist halt ein bestimmter 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 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 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 brechen 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 quasi ein ähnliches Ding 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 so, hey, das ist nicht okay, so geht das nicht.

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

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

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, 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, 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,

ich meine, der Name ist so ein bisschen...

Ja, die Proprietäre und so, genau.

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 ja 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.

Irgendwie, ich weiß nicht, Microsoft hat da 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.

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 es aber.

Also das, was ich so unter der Hand höre, ist natürlich Bullshit, wissen wir alle.

Aber Q-Star haben sie gefragt und hat gesagt, vorher, ihn schmeißen raus.

Bitte?

Sie haben Q-Star gefragt und Q-Star hat gesagt, schmeißen raus.

Das ist die nächste Witz.

Achso.

Ja, das kann natürlich, ja.

Ja, ich weiß auch nicht.

Also, ja.

Ja, dann gab es ja auch diese ganzen komischen Lobby-Aktivitäten.

Irgendwie jetzt auch was AI-Act, was sich nicht in Europa angeht und so.

Wo man ja auch sagen muss, mhm.

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

Nein, 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 schon wieder ein ganz neues Fass, das Fass 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, nein, der Wunsch ist richtig, würde ich sagen.

Ja, also, 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 Lobbybestrebungen.

Ja, 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, das ist ja noch nicht

unter Dach und Fach,

es ist ja 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, 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 selber machen, kann ich mir ein Lama

feintunen 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 Altman ist ja auch wieder zurück

zu OpenAI, heißt 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 dass irgendwas dran machen kann, wenn da jemand eine Milliarde investiert.

Nein, nein, nein, das ist überhaupt gar keine Gefahr.

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

Nein, niemals. Warum sollte denn niemals sich jemand korrumpieren lassen?

Ja, also, nee, nee.

Ja.

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.

Also das war sozusagen die

leichte Unterhaltung zum Thema.

Kurz vor Weihnachten noch mal ein bisschen Advent.

Ja.

Advent of God und was kann man auch wieder spielen?

Ja, genau. Was hatten wir noch?

News.

Du hast noch eine wichtige News.

für Python.

Gil Removal. Genau, Gil 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

Pablo Galindo Salgado

irgendwie den

Release-Managern für die letzten

Python-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 jetzt, 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 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.

War das Cinder X, das ist die letzte Folge?

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

Da haben sie, haben sie denn nicht 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 da gab es mal eine sehr interessante

Episode, ich habe jetzt wieder vergessen, wo und wann,

aber wo er darüber geredet hat,

was man so für 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 Shownotes gelinkt, wenn ich mich recht erinnere.

Kann sein, ja.

Also genau, das kann man, also ja, ich habe es noch nicht gehört.

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.

Ja.

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

Ich kann mich an den Januar und den Februar erinnern,

wo ich 1.000 Passwörter umstellen musste.

Das war super.

Wo ich dann gesagt habe, ja, okay, so prinzipiell ist OnePasswort

jetzt auch nicht so viel besser zum Beispiel.

also, aber

zum Glück sind sie noch nicht irgendwie

hops genommen worden. Ja, das hat sich jetzt geändert.

Jetzt ist auch OnePasswort hops genommen worden.

Und zwar über Okta.

Ich manchmal denke so, ok, Okta ist auch so ein,

ich verstehe nicht genau, warum Unternehmen sowas verwenden,

aber ok. Ja, ist ja total super.

SSO und so, muss man alles über so einen

Anbieter machen. Ist Okta nicht auch

hinter Zero aus? Ja,

aus Zero, ja.

Ja, da-dum.

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, also das,

ja. Ich finde es schwierig tatsächlich.

Wir hatten ja letztes Jahr schon mal, ja, 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 KeyPassXC 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 ein 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

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 Keepers.

Das sah schon gut aus,

aber das Problem für mich ist halt auch

der Support von irgendwie so

Familie und Verwandten.

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 geht es halt nur zweimal oder so was

und einer ist dann halt im Bankschließfach

und den brauchst du halt dann und so.

Das ist auch gar nicht eine schlechte Idee, finde ich.

Ja, also. Was ich mir

wahrscheinlich anschauen würde, wenn ich

jetzt was will, was ein bisschen mehr

Cloud 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, 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 und gucken, was da passiert.

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, wie teile ich

auch, jetzt hatten wir ja auch letztes Mal, glaube

ich, irgendwie Geheimnisse

durch Entwicklungsteams irgendwie.

Auch nicht so einfach.

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.

Ist halt auch dann wieder irgendeine

Party, die dann halt Zugriff darauf hat, aber gut, dass

das jetzt nichts Kritisches 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, also

die Überleitung war jetzt ein bisschen hakelig.

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 Taste-Framework, 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

vielleicht auch.

Das erzählst du ja vielleicht auch öfter.

Also ich fand auf jeden Fall den Vortrag, den

auf der letzten EuroPython darüber gehalten hat, schon ziemlich gut.

Der war spannend.

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 Open-Source-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

Test-Framework.

Inzwischen muss man sagen, dass

wirklich so das Default eigentlich PyTest ist.

Also Nose-Test ist sogar deprecated, oder?

Nose, ja, ja.

Nose-Test gibt es auch noch.

Ah, Nose-Test, ja, Nose-Test.

Da habe ich 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 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

JetBrains.

Und da hat PyTest,

ich glaube, vorletztes Jahr oder so,

die 50%-Marke

geknackt.

Ich hätte sogar mehr geschätzt.

Ja, wobei

irgendwie 30% halt sagen, sie nutzen

gar kein Test-Framework.

Okay.

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 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 Noten

Aufschlü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 Zeugnisnoten und so, das

muss halt schon irgendwie

keine Box haben, idealerweise.

Also ich finde auch, also so kritische Teile der

Infrastruktur sind ganz gut, wenn man die testet.

Also sowas wie Authentifizierung, Autorisierung

oder sowas, sollte man schon irgendwo mal gucken,

dass das stimmt.

So die kritische Business-Logik.

Also weiß ich nicht, 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

habe ich das auch gemacht, weil einfach ich das mal

machen wollte.

Ob das jetzt nötig wäre,

weiß ich nicht.

Ja, es wird schon anstrengend, also gerade wenn man dann

externe Komponenten drin hat,

irgendwie, oder eine

GUI-Applikation schreibt oder so,

dann wird es schon schwierig irgendwann.

Ja genau, also welche Enden muss man danach testen, ne?

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 dann 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 dann 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 mach's ganz gerne

bei Bugs, 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-Applikation,

da muss ich das Feature irgendwie

erstmal implementieren und erstmal sehen,

wie das aussieht aus User-Sicht, aus

Code-Sicht auch, bevor ich

ja irgendwie sinnvoll Tests dafür schreiben kann,

finde ich.

Klingt sehr vernünftig, würde ich

ganz genau so 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 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 mache ich doch

lieber was anderes. Und

wenn man da zuerst die Tests schreibt,

dann schmeißt man die Tests ja mit weg.

Ich habe dann mal, es gab auf

Twitter irgendwie einen Thread, wo dann

weiß ich nicht, Harry Percival,

der auch dieses

Obey the Testing Go, der

ein Testbuch geschrieben hat für Python,

meinte, dass Leute doch bitte mal

TDD verwenden sollen und sich mal ein Brief reißen

wollen. Dann werde ich so, ich mache das mal so.

Ich weiß nicht, ich habe so das Gefühl, wenn ich

zuerst die Tests schreibe, dann ist das eine totale Verschwendung, weil

wenn ich schmeiße, dann oft Sachen wieder weg.

warum sollte ich da Test-Sachen schreiben, nicht wieder?

Nee, nee, das ist ein Spike, das ist auch TDD,

das ist schon okay.

Na gut, ja, aber ja, also oft

muss man erst mal sehen, ob irgendwas so funktioniert,

wie man denkt und dann...

Wenn man zum Beispiel die Modelle jetzt noch nicht hat von so einem Problem,

oder die einfach definieren muss, also manchmal muss man ja irgendwie

Fixes schreiben dann erst mal, 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 erst mal so, um zu sehen,

ob das in der UI funktioniert.

Das wäre dann Integration-Test?

Wie gesagt, an der Stelle kann man noch nicht

so gut Text schreiben. Wenn ich mit Tests 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 anknüpfen.

Da hat jemand letztens ganz einen lustigen

Thread aufgemacht, wo er fand, ja,

er hat mal ChatGPT gefragt, wo

das PyTest-Logo herkommt

und ChatGPT meinte dann,

ja, ich hätte das designt.

Ist Quatsch.

Ist billiger 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, dpt lügt

bei Python regelmäßig. Das denkt zum Beispiel auch,

dass irgendwelche anderen Menschen den Python-Podcast machen

würden, die es noch nicht gehört haben. Aber hey.

Ja, ich

habe dann tatsächlich mal rumgegraben

in den Mailing-List-Archiven und

rausgefunden, warum das so eine Pornflöte

ist. Ach okay, das ist was anderes.

Soll nämlich tatsächlich an diesem

Testing-Goat als Maskottchen

nachher auf diesem Buch anknüpfen,

weil Pornflöten eben genutzt

wurden wohl, um

um Ziegen zu

herden, wie sagt man

in Deutsch?

Zu hüten, ja, ja.

Hm.

Ja.

Ich fand das mit dem Chat-Video dann ganz witzig.

Ich hab danach noch mal so ein bisschen nachgehakt

und find so, nö, das war nicht ich.

Und dann meinst du, ja, nee, es tut mir leid,

es war Armin Ronacher.

Ach so.

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

Und da meinte 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 halt auch nicht stimmt.

Ich habe gerade auch noch mal 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.

Nee, das ist 3.5.

Das ist 3.5, okay, interessant.

Ja, das ist halt, weil er sich

manchmal auch sehr fantasiert halt.

Ja, gut.

Sicheres Auftreten bei vollkommener Ahnung

zu Bescheid. Jochen, was fällt dir dazu ein?

Dass mir auf jeden Fall

die Panfurter besser gefällt als ein Schäferhund

als Logo für PyTest.

Ja, die Panfurter sind super.

Ja, 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 PyTest-Schulungen

geht das überhaupt, also ich habe irgendwie so ein bisschen

ich mache auch manchmal Schulungen, auch so

Python-Einführungen oder halt auch mal zu

speziellen Themen und ich habe

immer so das Gefühl, ich weiß nicht so genau, ob ich

ob das, wie ich da

wie man da am besten

Wert irgendwie schafft für die Leute, die

darin 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 eine

Wegschmeißen nochmal machen, Wegschmeißen nochmal

machen, Wegschmeißen nochmal machen. Ja, oder man muss sich 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

und träge von, 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 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

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 zu Europython da

in Bilbao,

also Spanien.

Da wurde ich von Holger Kree,

also nicht ich, aber Holger Kree

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

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 auch das erste

Firmentraining dann von ihm übernommen,

weil er eh langsam aufgehört hat mit

PyTests 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 da

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 dann 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 mich erst 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.

Und dann 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 bei PyTest, aber ich würde noch mal

kurz gerne bei Coverage einhaken,

weil 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, das Blöde ist halt dann, wenn 100% coverage,

also der ganze Code ist durchgelaufen,

aber es ist trotzdem irgendwas kaputt.

Genau.

Kann einem halt auch passieren, ja.

auch schwierig, da

Prozent Coverage gerade in ein Team

sich irgendwie als Ziel zu setzen, weil

dann wird es bestimmt Leute geben,

die dann einfach diese Zahl hochtreiben, ohne

wirklich noch gute Tests zu schreiben.

Ja, genau, weil, ja, das würde ich auch sagen, wenn man es halt nur macht,

um irgendwie, ne, irgendeinen Ast nochmal

zu, durchzuwandern,

ohne dass es halt irgendwas bringt, das ist halt blöd.

Aber gibt es da sowas, wo

ihr sagen würdet, so aus euren Eigenprojekten

so Pi mal Daumen, so eine Coverage ist okay?

Hm.

Ich würde, also ich weiß nicht,

also meistens, wenn ich nicht drauf achte, lande ich

irgendwo so bei irgendwie ein bisschen über

80 Prozent oder sowas.

Ja, 80 war 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,

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 bei der Web-Applikation

jetzt die Views einfach nur durchgehen und gucken,

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 man natürlich

am 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.

Ja, am Schluss muss man sich danach

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. Das ist irgendwie eine

Fehler-Condition, 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 jetzt von einer

kleinen Funktion, von irgendeiner Klosche

irgendwie der Contract ist. Also wenn 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

wusstest halt, dass das, was reinkommt, dann auch

dem entspricht vielleicht, oder dass man halt

das eng zuckt. 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 wenige

irgendwie so

End-to-End-Tests oder so.

Man kann 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. Genau, das willst du

natürlich nicht. Ob weiße, in den Meter links oder rechts sind, aber wenn halt

irgendeine Änderung von irgendeinem Designer kommt, dann deine ganze

Pipeline sieht jetzt mal auseinanderfliegen. Das 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ängt oder was teuer ist oder sowas,

dann sollte man da vielleicht ein bisschen mehr Hirnschmalz 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 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 einer Funktion

nur 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 passiert, auf einmal passiert,

also ein bisschen sich so von diesem

ein Ding für eine Sache Prinzip verabschiedet,

dann wird das halt auch relativ schwierig zu testen.

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.

Weil das sind so widerstreitende Dinge.

Also ich würde ja auch zustimmen, 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

ist es 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.

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

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,

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, 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 es 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,

die eine Art ist besser wie die andere Art.

Ja.

Wenn ich jetzt ein Command-Line-Tool teste,

bietet es sich vielleicht an,

da eher End-to-End-Tests zu schreiben,

weil ich dann wirklich auch den Output und so testen kann

und

eher sparsam

für einzelne Funktionen

Unit-Tests 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 dann

ein Firmware drauf 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 Knöpfe 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 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, 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.

Ja, Fixchance.

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 und kann ja 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 mit Pytest Playwright

oder so, dann da ist ja auch eigentlich

jeder Test im Grunde verwendiger.

Man muss halt den Browser aufmachen,

dann da überhin und dann...

Ja, von da

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 Fiction und was

Fiction sind und wie man die baut oder

macht ihr das mit Factories

oder macht ihr das ohne Factories oder

sind Factories doof oder

du hast ja so verschiedene Sachen und also was

sind überhaupt Fiction 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 weiß nicht, gibt es da ein einfaches Beispiel?

Also wenn wir

mit einem normalen Webclient zum Beispiel arbeiten

wird, dann wird halt eine Fixture der User und einer

ein Client und dann guckt man, wie das interagiert

oder

wie baut man das? Ja, am Schluss ist eine

Fixture im Prinzip

einfach eine Funktion, die also als

PyTest-Fixture

markiert ist oder dekoriert

ist und

diese Fixture kann entweder

irgendwelche Setup-Schritte

vornehmen für den 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 so was

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 nicht gut 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 Fixer

in die Parameter

vom Test schreibt und dann das

automatisch ausgeführt wird. Genau, dafür schreibt man die Funktion

ja quasi in den Conv-Test einfach rein.

Ja, nö, musst du 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 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 eine, auf eine Fixture

in PyTest 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

von deiner Wahl.

Es ist schon eigenartig, ja.

Also ich sag so, dass

inzwischen habe ich es 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, sondern eher was Yielded.

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, 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 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 viel komplexe

Tests darzuschreiben, nur 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, ist irgendwie die Parametrisierung

mit beispielsweise Data Classes oder

sowas, dass man halt tatsächlich

eine Plethora

hundert verschiedene Dinge erstellt

und 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

noch reißt. Ohne jetzt direkt

auf Hypothesis zu gehen, halt Hypothesis

testet nochmal, also mit zufälligen

Figures, wenn ich das richtig verstehe, ja, oder

Zufallswerten für Dinge

in den Figures.

Ja, vielleicht noch kurz zur Parametrisierung.

Wenn ich mir jetzt PyTest 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.

Oder hast du auch eine Seite

übrigens, kurzer Exkurs, F-String

irgendwie, Docs, kann das sein?

fstring.help, genau.

Oh ja, die habe ich auch schon oft

angeguckt.

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

an der PyCon Germany und dann

abends 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, wenn ich zwischendurch da reingucke.

Das ist echt gut.

Habe 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 Testframes.

Merks. 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

quasi

sozusagen wie unterschiedliche Parameter,

also wird der Test auch mehrfach ausgeführt mit den

Du meinst, wenn du mehrfach hintereinander yieldest,

weil das beim ersten Aufbruch, beim zweiten Aufbruch

und beim 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.

Mit der Idee, wenn du irgendwie

mehrere Backends hast oder

mehrere Implementationen, die sich aber eigentlich

gleich verhalten sollen,

dass dann halt eine ganze Batterie von Tests

über beide beispielsweise laufen lassen kannst.

Ja, genau.

Mir war das nur in Erinnerung geblieben, als das auch

eine Art, wie man Parametrisierung machen

könnte, aber tatsächlich sehe ich

eigentlich auch immer eher nur PyTest, Parametrize

und den anderen Weg eigentlich. Genau, du kannst halt

beide Sachen gehen, entweder direkt an den Testrandschreiben

oder halt an die Fiction. Genau,

aber jetzt sicherlich ein bisschen exotischer.

Ja, das ist

halt ganz nützlich, gerade für das Teardown.

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, 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 einzelne Dinge

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 zum Beispiel sagen,

parametrisiere das mal für keine Ahnung

10 oder 20 zufällige

Nutzer aus so einem

Factory heraus und benutze

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 Spitalfall, 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

darauf sprechen werden.

Also, Jochen, uns wird auch kurz nicht stören.

Ja, ich hab sowas, Factory Boy und sowas

früher mal verwendet, aber ich mach das eigentlich

inzwischen nicht mehr.

Ich hab...

Mach doch kurz fertig.

Ja, also einfach deswegen, weil

ich finde, das macht einfach zu viel Magie

mit irgendwelchen... Da hast du dann auch wieder so Dekoratoren

für die...

Also, 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 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

Applikation 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 Boy und sowas gar nicht mehr.

Ich habe gerade den Blogartikel 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 halt quasi das, was ich meinte, ne? Default Keyword

Arguments mit vielleicht einem Faker dazu

und dann hast du halt eine parametrisierbare

Art und Weise. 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 plausible Daten hat. Okay, ja.

Du kannst FEC ja auch den Seed mitgeben zum Beispiel.

Ja, und dann ist es immer gleich.

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

Ja, klingt gut.

Das ist ein Projekt, das 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 zum Beispiel 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

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,

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

ein Compress und ein Decompress

hat, dann kann man das einmal durchlassen,

einmal sagen, Compress, einmal

Decompress, dann soll das Gleiche wieder

rauskommen.

Decrypt, Encrypt, Encode,

Decode, alles so diese Paare,

die sich halt umkehren sollten.

Ja, dann merkt man relativ schnell, ob man

irgendeinen Case hat, 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 mir 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?

Irgendwann was kaputt ist,

was 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 irgendwie

in den Dingen so verwendet, die ich so mache.

Ja.

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 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. Also wenn ich halt gemerkt habe,

okay, Herr Passus, jetzt langsam halt eine Unit

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

Xcades gefunden, die ich rausschmeißen konnte und konnte

dann mir sinnvoll überlegen, okay,

der Eingabewert ist jetzt vielleicht doch nur maximal

siebenstellig oder so, ja,

und nicht noch mehr. Und dann wurde dann

der Test natürlich dann viel schneller und dann habe ich halt gesagt,

ja, sorry, aber mehr ist jetzt hier einfach nicht erlaubt

und das halt direkt mit

abgefangen. Und so, das war

glaube ich, ja, an der Stelle eine gute

Strategie, um mal so ein bisschen so die Grenzen zu gucken,

was überhaupt an I.O. da sinnvoll ist

auch. Oder so eine Sanitization

zu machen an zwei Stellen oder so, was gut ist.

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

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. Also ich mag

das sehr gerne, wenn Tests halbwegs schnell durchlaufen.

Ich finde das immer 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 ein, zwei Sekunden

nebenbei in der IDE, dann kann man sie dann

parallel laufen lassen und sieht direkt, wenn man irgendwas kaputt

gemacht hat.

Das ist auch gut.

Ja, wäre schön, aber bei größeren Projekten

ist es

irgendwann nicht mehr realistisch.

Aber da,

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