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

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