Ja, hallo und herzlich willkommen zum Python-Podcast in der 24. Episode.
Heute geht es bei uns zum Test und wir haben wieder einen Gast, der Ronny ist da.
Hi.
Hi Ronny, hallo.
Und der Jochen natürlich auch.
Ja, ja, ich bin dann auch da.
Ja, schön, dass ihr alle wieder eingeschaltet habt.
Und Ronny, erzähl doch mal was von dir. Möchte ich einmal kurz vorstellen.
Ja, ich heiße Ronny Vidrilia, ich arbeite in Köln bei Amint Innovation.
Bin da jetzt seit einem Jahr ganz offiziell Tech-Evangelist für Django.
Habe jetzt meine acht Jahre, die ich da bin, auch Großteils mit Backend-Arbeiten und Django verbracht, habe in Köln Wirtschaftsinformatik studiert, also eigentlich eher so ein Beraterstudiengang, aber ich hatte immer mehr Spaß eigentlich am entwickelnden Beraten, beziehungsweise Beratung mit Entwicklung zusammen.
Kann ich ja gar nicht verstehen.
Und genau, wir haben uns eigentlich kennengelernt, du warst Pei Cologne oder Düsseldorfer?
Ja, und du hast dann dieses Meetup ausgerichtet, das Django-Meetup in Köln.
Hatten wir das nicht vorher schon?
Ja, wir haben uns auf irgendeinem der Peikolons mal gefragt.
Peikolons bestimmt, da haben wir uns bestimmt schon mal gesehen.
Genau, und wie Dominik gerade schon gesagt hat, seit jetzt glaube ich einem knappen Jahr richten wir bei uns im Büro bei Ambient das Django-Meetup Köln aus.
Und genau, da sind die beiden auch immer regelmäßige Gäste.
Falls ihr uns live kennenlernen wollt.
Bis Corona all das verunmöglicht hat, sozusagen.
Also na gut, es gibt halt das virtuelle Meetup.
Und ja, genau.
Das ist nicht mehr ganz das Gleiche.
Ich fand es auch immer schön, die Leute live zu sehen.
Apropos live sehen.
Wir haben heute tatsächlich eine Testfolge, die einen Test macht.
Und zwar sind wir zum ersten Mal nicht im Wintergarten,
sondern diesmal draußen und sitzen in einem Restaurantgarten.
Wir waren auch schon mal woanders, aber wir waren noch nie draußen.
Ja, genau. Und das ist jetzt quasi das erste Mal live
vor Ort draußen. Also entschuldige mir so ein bisschen
die Hintergrundgeräusche. Das ist ein bisschen urbanes Leben.
Genau.
Ja, schreibt da gerne mal Feedback zu.
Klingt das ganz schrecklich furchtbar? Oder kann man
damit halbwegs leben? Ich meine, das ist natürlich angenehm.
Also gerade wenn es warm ist, irgendwie eher draußen zu sitzen
und irgendwie ein bisschen was Kühleres
zu trinken, ist natürlich schon sehr viel angenehmer als
jetzt. Dankeschön.
Prost.
Naja, hört sich ein bisschen zu fern an. Die Werte sind zu voll.
Ja, aber eben wenn man in so einem kleinen Raum sitzt, also das ist ja immer das Problem mit der Akustik, man braucht entweder einen kleinen Raum, in dem viel Zeug ist, damit es halt nicht so hallt, weil Hall ist immer so der Feind von guter Akustik, oder halt Weite. Hier haben wir jetzt Weite und wir haben leider sogar ein bisschen Wind, vielleicht hört man den auch.
Ja, auf jeden Fall, genau. Also wenn großer Raum, also so draußen ist eigentlich auch nicht schlecht für die Akustik, aber Wind ist natürlich schon mal wieder nicht so toll. Aber ja, ich bin mal gespannt, wie das funktioniert und wir haben ja auch ein Realist-Equipment, das wir nehmen auf, ohne irgendwie Laptop oder Computer, einfach so mit so einem portablen Aufnahmegerät und den üblichen Headsets und da mal schauen, wie das so geht.
Ja, aber du kannst gerne noch mal ein bisschen über die Gerätschaften erzählen, du machst das schon letztes Mal irgendwie.
Naja, das ist jetzt einfach so ein Zoom H6, das ist halt so ein Field Recorder, das wird jetzt beworben. Das hat halt auch so XLR-Eingänge für Mikrofone, macht Phantomspeisung und dann ist da noch so ein Kopfhörerverstärker dran, wo dann halt die Ausgänge, die alle das gleiche Line-Out-Signal von dem H6 kriegen, nochmal dran hängen, damit man sich auch selber und die anderen hören kann.
Und genau, also was wirklich eine tolle Kombination ist, ist halt sozusagen die Standard-Podcaster-Konfiguration zur Zeit, glaube ich, die die meisten Audioqualität bietet für Geld, ist halt so ein Zoom H6 plus irgendwie diese HMC 660X oder C, keine Ahnung, Headsets, weil man kann an dem Zoom H6 nämlich auch 12 Volt Phantomspeisung einstellen.
und muss nicht
löten und braucht keinen Adapter
oder so und die Dinger funktionieren einfach
an dem Ding direkt, was halt bei den meisten
professionellen Audio-Interfaces nicht geht.
Ja, mal schauen, wie das so wird.
Ja, ich bin gespannt auf die Folge und wie sich das hinterher anhört.
Also gerade mit dieser Hintergrund-Akustik. Also man hört ja
manchmal den Wind rauschen, das Lachen der Gäste,
die leise Musik.
Ronny, Tests heute?
Ja.
Oder wollen wir zuerst irgendwie, gibt es irgendwelche News?
News aus der Szene.
Ja, also Dango 3.1 kam ja raus, ich weiß nicht,
jetzt ist es tatsächlich final. Und Wagtail
wurde auch schon auf Dango 3.1 gearbeitet,
das habe ich auch noch mitbekommen. Ja, es gibt eine neue
Wagtail-Version, wobei die, glaube ich,
war nicht so weltbewegendes dabei. Ja doch, es geht jetzt
mit Dango 3.1. Ach so, ja.
Okay, gut. Denn ich habe direkt tatsächlich
umgestellt. Du hast einen tollen Artikel
geschrieben übrigens auch.
Ja, das war, ich meine, das ist halt irgendwie so
mehrere
Probleme auf mit einer Klappe
fliegen, erledigen
halt sozusagen. Ja, wir schreiben auch noch gerade
schreiben wir an so einen Artikel, deswegen habe ich
den zuerst irgendwie
zur Release von
Django 3.1 halt sozusagen veröffentlicht
und davor haben wir halt diese Asung-Folge
gemacht, die halt... Kannst du Django News, Ronny?
Ja. Ja, weil der erste
Artikel war von ihm. Ich habe es auch gesehen, ich war
ja, ich hatte ja schon
intern vorher
mitbekommen, dass du einen Artikel geschrieben hast.
Nicht schlecht.
Ja, was mich, also tatsächlich hat es
Jochen
wird gerade von einer Wespe bearbeitet und die kriegt
gerade über sein Brillenglas.
Jochen mag Insekten sehr gerne,
wie ich schon mitbekommen durfte.
Aber er bleibt relativ entspannt.
Also ehrlich gesagt, die Insekten mögen mich mehr als sie.
Finde ich.
Das ist etwas beunruhigend. Na gut.
Gab es doch diesen Song.
I don't like the insects, but the insects like me.
Ja, genau.
Aber genau, was ich
daran eigentlich ganz gut fand,
ich weiß jetzt nicht, der Artikel, naja, ich habe irgendwann auch einfach
mir gedacht, ich habe keinen Bock mehr weiterzumachen,
jetzt reicht es. Aber er hat relativ
viel Aufmerksamkeit, also mehr Aufmerksamkeit gekriegt,
als ich gedacht hätte. Und ich
glaube, das lag halt daran, dass einfach auch viel Arbeit
drin steckt, fürchte ich. Ja, ich wollte gerade sagen,
also ich habe ja irgendwie mal so angefangen damit
erstmal, ne. Jochen hat mir so um die Ohren gehauen,
das ist unglaublich. Dann meinte er so, nee, das geht gar nicht.
Und hat dann irgendwie 15 oder 16 Seiten
drangehängt, wie man es richtig macht. Ja, okay, danke, Jochen.
Ja, aber ich wollte das
eigentlich alles gar nicht. Aber na gut, also manchmal braucht man
halt auch jemanden, da braucht man irgendwie so einen Anstoß, um das
dann zu machen und den Handwänden damit. Und ja,
gut, jetzt ist es draußen und gut.
Also insofern, ja, also
viel Arbeit in irgendwas stecken hilft.
Ja, wenn das irgendjemand weiterhilft, keine Ahnung.
Ja, genau.
Ach, es gab noch eine neue
Release-Kandidat
für Python 3.9.
Den ersten gibt es jetzt.
Also, und Leute, die das
verwenden, haben schon gesagt,
es funktioniert eigentlich alles ganz fluffig.
Was sind denn die Neuerungen von 3.9?
Wir haben das bestimmt schon mal besprochen.
Wir haben jetzt ja kein Recht an den hier.
Wir können das nicht einfach nebenbei...
Wir können das nicht einfach, weil so
online recherchieren geht
halt gerade eben nicht. Aber ansonsten
hat, weiß nicht, sonst irgendwelche Neuigkeiten...
Nee, ne?
Ist dir was eingefallen? Nein, außer
Django 3.1,
was ich jetzt auch schon nutze, funktioniert gut.
Jason Fields sind super. Doch, mir fällt noch was ein, und zwar
ist von Daniel Roy Fieldroy das
Buch Two Scopes of Django
in der Version 3, hat der gestern Abend
seinen Twitch-Kanal hochgefahren,
weil es jetzt offiziell Redaktion ist.
Ah, okay, ich hatte es schon gekauft, aber
immer die Updates nur gesehen, nur die dann nie,
weil ich dachte, ach, ich warte auf die fertige Release.
Wenn ich jetzt weiß, das Release ist super, dann hole ich mir mal
den. Ganz genau, das war gestern
Abend. Ah, sehr schön.
Ja, nö,
ansonsten, genau, können wir dann
vielleicht direkt mit dem echten Thema
einsteigen. Ja, wollen wir vielleicht noch kurz
einen Überblick geben? Also ich glaube, wir reden einfach los, wie immer,
über Tests und so ein bisschen mehr Tests und Tests
und Tests und Tests und wir testen jetzt, ob der Test funktioniert
mit den Tests. Mögt ihr Tests?
Jochen?
Ja, also ich habe lange Zeit, ich habe früher die Leute, die so anfingen mit TDD oder so.
Ich finde Tests total furchtbar.
Das hat dann irgendwie, als ich noch keine Tests geschrieben habe oder noch nicht so viele, da habe ich so ein bisschen über diese Leute immer gelächelt.
Ich so, ah ja, die mit ihrem komischen statischen Dings da, Java und so und Testschreiben, höhö, das mache ich alles einfach mal so eben aus der Hand.
Mein Code ist so perfekt, den braucht man gar nicht.
Einfach keine Fehler machen, so einfach ist das.
Genau, das ist alles kein Problem.
Und dann irgendwann dachte ich so, okay, ich bin vielleicht einfach nicht so der Typ für längere Programme. Ich schreibe gerne so kurze Sachen, die so auf eine Bildschirmseite gehen oder vielleicht ein bisschen länger sind, aber habe das nie so reflektiert, woran das eigentlich liegt.
Und dann, als ich irgendwann angefangen habe, Tests zu schreiben, weil das halt in irgendeinem Projekt dann erforderlich wurde, merkte ich so, oh, ach, ich kann ja vielleicht doch leckere Programme schreiben. Mit Tests geht das plötzlich. Und das ist halt, man kann halt sich quasi ausruhen. Entweder man hält halt den kompletten State im Kopf und weiß dann halt, dass man wahrscheinlich keine Fehler gemacht haben wird, weil man das halt weiß, wie jeder einzelne Teil funktioniert und miteinander interagiert. Oder wenn man das halt nicht mehr wissen kann, weil es einfach zu viel wird, dann braucht man halt Tests. Ansonsten passieren schreckliche Dinge. Das ist halt einfach so.
Oder halt auch für Refactoring. Das ist halt auch immer ein Riesenargument für Tests.
Okay. Magst du Tests, Johnny?
Ja. Ich muss gestehen, wenn ich unter Zeitdruck viel entwickeln muss, dann ärgere ich mich manchmal nachher, dass da noch so viele Tests übrig bleiben, die man schreiben muss.
Aber generell finde ich es eine super Sache. Und wie gesagt, allein schon wegen Refactoring.
ich arbeite an mehreren
Django-Projekten, die jetzt schon Jahre laufen
und ich weiß, wie mühsam
das früher war, als wir noch keine
Tests da drin hatten und wie
unmöglich es war, irgendwelche Sachen anzufassen,
ohne
dass man nachher Stunden
am besten tagelang irgendwie...
Genau, vor allem dann so
zerbrechliche Sachen, wie man hat dann
zum Beispiel irgendwie eine Überstundenerfassung
oder sowas gebaut und da dann irgendwie alle
Sonderfälle irgendwie zu bedenken und durchzutesten
manuell zu Fuß,
vor allem, wenn du noch so Späße hast wie mit Daten
und da musst du immer noch quasi in,
also ohne, dass man irgendwie jetzt in einem Testumgebung
ist, wo man das Datum einfach mocken kann,
so in manuellen Testen
das Datum dann irgendwie und dann so lustige
Sachen wie Wochenenden und Feiertage.
Dafür bin ich schon sehr, sehr
froh, dass es Unit-Tests gibt und dass die so gut funktionieren.
Ja.
Ja, ich muss sagen, also ich mag
Tests eigentlich gar nicht, aber sind in gewisser Weise,
fand ich ja notwendig, aber ich habe erst mitbekommen,
ich bin jetzt noch nicht so lange dabei, dass es eine große
philosophische Debatte gibt zwischen Menschen, die gerade
kronheimlich viele Testabdeckungen, also Coverage
nennt man das ja, haben am liebsten
150% des Codes sollen getestet
werden und andere Leute sagen, ja, ist eigentlich
völlig egal, einfach ein Integrationstest,
ob überhaupt so die Permissions so sind, wie
ich mir das vorstelle und dann, wenn halt was
schmiedschlägt, dann schreibt man danach dafür einen Test,
dass es nicht nochmal passiert.
Irgendwie so dazwischen ist so
die Wahrheit, ich weiß nicht, ob es sowas gibt,
wie so manches Mal.
Aber ich glaube auch,
also ich meine, es gibt ja das
berühmte Pareto-Prinzip, 80-20-Regel,
Und ich glaube, wenn man versucht, 100% der Sachen abzudecken, ich glaube, es gibt einfach Dinge, da ist einfach der Overhead so viel größer, dafür irgendwie Tests zu bauen, dass man da, glaube ich, auch einfach riskieren kann, dass gewisse Dinge vielleicht einfach mal in die Hose gehen dürfen.
es wird auch so starr. Also wenn du halt ganz, ganz,
ganz viel testest, dann kannst du eigentlich
ja nichts mehr ändern, ohne dass
irgendein Test fehlschlägt. Ich meine, du merkst dann zwar, was dann
fehlgeschlagen ist vielleicht, aber
das macht einen doch sehr unbeweglich und
du hast halt tatsächlich auch, wenn du refactoren willst,
wie du eben sagtest, Ronny, das
Problem, dass du ganz, ganz viele Sachen
und die Teste anfassen musst, weil vielleicht auch die
Tests refactored werden müssen dann.
Ja, also ich würde auch denken, es kommt halt
auf den Anwendungsfall an. Also wenn du halt irgendwie eine
kleine Webseite hast, die irgendwas
keine Ahnung, für dich und ein paar Freunde
irgendwie macht, da braucht man vielleicht keine Tests,
weil wenn irgendwas schief geht, dann fixt man das halt und
es hat ja keinen gestört, dass es irgendwie schief gegangen ist.
Steuerprogramm vom AKW
bräuchte vielleicht ein paar mehr Tests.
Genau, da würde man sich dann vielleicht freuen,
wenn die bemerken, dass etwas schief läuft, bevor es
irgendwie die ganze Region mit in den
Abgrund reißt, aber genau.
Und da braucht man halt vielleicht viele und gute Tests.
Und ja, also
ich meine, nur ein paar
Integrationstests zu haben, ist ja auch schon mal
auf jeden Fall besser, als keine Tests zu haben. Auch die fangen natürlich
dann schon Sachen. Auf der anderen Seite
ist es schwierig. Das mit den Metriken ist
immer so eine Sache. Ich meine, es ist auf jeden Fall
immer auch besser, irgendwas zu messen, als nichts zu messen
und dass man irgendwas hat, worauf man optimieren kann.
Aber gerade, wenn man jetzt so
schlechte Tests schreibt, dann kriegt man
mit denen oft eine gute Testabdeckung hin.
Weil man hat dicke
Integrationstests, die ganz viel
Code aufrufen.
Aber eigentlich sind die halt
eher nicht so toll, weil die sind
halt langsam und
dann die
sind auch schwer zu ändern, wenn man dann Code ändert
und
was heißt das eigentlich 100% Test-Coverage?
Ich meine, die Brand-Coverage ist ja auch nochmal
vielleicht so eine Geschichte, das geht jetzt übrigens mit der
neuesten, mit der Version
5 von Coverage, geht das auch, dass man halt
dem sagen kann,
sag mir doch mal, wie viele von den
If-Verzweigungen, also es reicht
nicht, dass das einmal drüber gelaufen ist, sondern
auch, ob die tatsächlich
beide Pfade genommen haben, ob irgendein
Test getestet hat, ob beide Pfade genommen werden
und dann sieht es halt
schon anders aus. Und ich weiß, dass es Leute gibt,
die dann sowas sagen wie, naja,
das geht auch mit Coverage Leaders auch, dass man
sagt, man kann auch zu jedem File
angeben, welches andere File
für die Abdeckung verantwortlich
sein soll. Also wenn man jetzt zum Beispiel im Django-Projekt
Models
py-File hat, dann sagt man,
okay, da
soll die Abdeckung gewährleistet
werden von Testmodels py
und die Abdeckung, die
daherkommt, dass das aus irgendwelchen anderen
Integrationstests heraus auch
aufgerufen wird, das zählt nicht.
Weil ansonsten kannst du halt mit
fetten Integrationstests deine Coverage hochbringen
und, aber eigentlich ist das
überhaupt nicht das, was du haben willst, sondern was du eigentlich haben willst,
ist, dass du sicher sein kannst, wenn du jetzt was änderst,
dass du tatsächlich
nichts damit kaputt gemacht hast und
das kriegst du gerade bei diesen dicken Tests
ja gar nicht so richtig mit. Also außer
du hast was wirklich Gravierendes kaputt gemacht.
Ja.
Ja, okay, wir sind durch mit Tests.
Nee, nee. Ja, keine Ahnung, aber wie ist das denn praktisch? Wann habt ihr denn mit Testen angefangen? Ich glaube, ihr seid ja irgendwie, ihr macht ja bei euch ganz viel Django schon lange.
Genau.
Und habt ihr von Anfang an Tests verwendet?
Tatsächlich nein. Ich meine, die Sinnhaftigkeit von Tests war uns natürlich schon klar, aber dadurch, dass wir halt im Agenturgeschäft sind, also sprich, da kommen Kunden und beauftragen dann irgendwas oder wir beraten Kunden, wie wir dann halt eine Software bauen, haben früher auch sehr viel Richtung, ja, so Businesslösungen, also wie man irgendeinen speziellen Business Case halt digitalisieren kann.
Das ist auch wegen dem Wirtschaftsinformatik-Hintergrund, weil das halt ein ganz gutes Match war. Und haben halt dann früher am Ende gesagt, okay, Tests schreiben dauert Zeit. Also das ist schon einige Jahre her, aber es war halt so. Ich meine, quasi die Idee ist genau das Gegenteil von TDD. Also sprich, du schreibst das bei deinem Code und danach schreibst du die Tests. Und das ist ja quasi ein Mehrwert für den Kunden, weil die Software dann besser funktioniert. Und haben dann halt sehr realistisch versucht, dem Kunden das zu verkaufen.
Und selbst bei technisch affineren Kunden war dann halt relativ schnell immer die Aussage, naja, es soll ja funktionieren und wenn es kaputt geht ohne Tests, dann müsst ihr es ja trotzdem ganz machen und sparen wir Geld, weil wir die Tests nicht bezahlen. Und das war dann bei uns so ein gewisses Learning, bis wir dann einfach…
Ich würde das ja den Kunden lernen lassen.
Wenn der Kunde auf die Nase fällt
und du kannst ihm das vorher erzählen
und er bezahlt es halt nicht,
dann fällt es halt auf die Nase.
Also man steht halt da ein bisschen blöd da.
Das ist schon richtig.
Aber viele, die ich so mitbekommen habe,
an kleineren Kunden vor allen Dingen,
die dann sagten,
naja, jetzt können wir es nicht leisten,
den Test machen wir jetzt nicht.
Die kamen dann irgendwann reumütig zurück.
Ja, wir haben jetzt eine Software gebaut,
es wurde kein Test geschrieben,
es funktioniert alles nicht mehr.
Wir haben irgendwas,
vielleicht haben die selber irgendwas angepasst.
Da konnte irgendjemand von den Menschen aus der Firma
so ein bisschen Dango und hat dann irgendwas umgebaut
und irgendwas kaputt gemacht oder irgendwas anderes,
was ihm erst später aufgefallen ist.
Ich muss sagen, also dafür,
dass wir erst, also dass wir die
ersten Jahre, als wir noch ganz klein waren,
tatsächlich keinen Test geschrieben haben,
haben die Sachen trotzdem überraschend gut funktioniert.
Also es wundert mich rückblickend auch.
Ihr seid alle so gut.
Aber es ist echt überraschend.
Also wenn ich heutzutage, wo ich das mit den
Tests weiß, dann werde ich so schnell nervös,
wenn ich für irgendwas Kritisches keinen Test schreibe.
Naja, auf jeden Fall, wir haben dann halt irgendwann einfach gesagt, komm, das ist einfach Teil der Programmierarbeit, das steht nicht zur Debatte. Und ja, seitdem machen wir das. Und ja, ich glaube, der…
Habt ihr richtig so eine Struktur da drin?
Also wir haben jetzt keinen Coding Guide in der Firma. Also ich meine, jeder kann es im Endeffekt machen, wie er möchte. Ich meine, natürlich haben wir halt diese typischen QA Schritte wie Code Review, Content Review und sowas. Das ist natürlich ganz klar, dass wenn dann jemand irgendwie der Meinung ist, dass irgendwie Tests so und so geschrieben gehören und dass irgendeine wichtige Funktion nicht hinreichend getestet ist, dann kriegt man natürlich den Ball nochmal zurück. Aber im Endeffekt gibt es da jetzt keine offizielle Guideline oder sowas, weil ich meine, wie es bei Python so schön heißt, we are all adults here.
Ja, also jeder weiß ja, was er macht und die Akzeptanz ist auch da. Also das finde ich halt bei uns auch ganz cool, dass unsere, die Geschäftsführer sind halt auch Wirtschaftsinformatiker, also auch Techniker. Das heißt, wir hatten, wir haben bei uns nie das Problem, was man halt sonst, zum Beispiel mein Studentenjob, so was ich öfters mal hatte, dass dann halt da ein Technikfremder halt sagt, das muss irgendwie ganz schnell funktionieren und dann wird halt lange gefrickelt und gewurschtelt und es kommt nie der Punkt, wo man mal das nötige Refactoring macht.
weil Nicht-Techniker dann manchmal halt nicht den, ja, den Mehrwert sehen. Ja, also dass man dann auch einfach unterm Strich halt sehr viel Geld sparen kann, wenn Code einfach maintained ist und vielleicht dann auch getestet.
Wir verkaufen das im Internen mittlerweile als Security-relevant. Also wenn es keine Tests gibt, dann ist ganz viel Sicherheitslücken da, man muss da sicherstellen, dass das nicht…
Also, ja, ich bin mir nicht sicher, ob es da nicht inzwischen, also, ich glaube, wir hatten das Thema auch schon mal in der Projektmanagement-Episode, aber ob da nicht tatsächlich ein echter Interessenskonflikt ist, weil es kann sein, dass ich aus einer Wirtschaftssicht vielleicht tatsächlich sage, okay, für die Qualität bin ich nicht bereit zu bezahlen, weil ich hätte gerne lieber mehr Geschwindigkeit.
Die Musik hat sich übrigens gerade eben geändert, ich hoffe, ihr hört das nicht alle. Es war eben so schön entspannt und jetzt haben sie ein bisschen mehr Beats reingebracht.
Ja, ich treffe das jetzt so ein bisschen
durch die Nackt.
Ja, also
es kann ja sein, dass ich aus einer wirtschaftlichen
Sicht sage,
das, was die mir an Qualität liefern, das ist mir ehrlich gesagt
zu hoch. Ich hätte gerne lieber
weniger Qualität und dafür schneller.
Und das hat den zusätzlichen
Vorteil, dass wenn es dann schief geht, dann kann ich zu ihnen
hingehen und mit ihnen schimpfen und sagen hier so
das hat nicht richtig funktioniert,
jetzt macht man noch schneller. Voll gut.
Ja, ich muss ja nur ein bisschen besser sein als meine Konkurrenz
und ein bisschen weniger zahlen für die Produktivität,
die ich da irgendwie rausquetsche.
Und dann schon läuft es bei mir
besser als bei anderen. Ja, aber dann wäre das
Problem bei der Entwicklerseite, weil dann kein
Entwickler dürfte sich darauf einlassen, weil...
Ja, aber ich glaube, Leute tun das dann
trotzdem und geraten dadurch auch in blöde Situationen.
Und das ist mir auch schon selber passiert.
Und man muss eigentlich als Entwickler und dann halt
vielleicht auch als Agentur, die das dann
komplett anbietet, eigentlich sagen,
okay, nee, das ist das, was ich an Qualität...
Also sozusagen, das ist eigentlich meine einzige Verantwortung,
ist zu sagen, ich übe meine Profession kompetent aus.
Und wie ich das mache, ist eigentlich meine Sache.
Und ja, du kannst halt das nehmen oder nicht.
Aber ich werde keine Einschnitte bei der Qualität machen,
weil hinterher bin ich eh der Blöde.
Wenn es schief geht, bin ich der Blöde.
Und ich bin sowieso der Blöde, weil ich irgendwie damit,
ja sozusagen auch mich selbst sabotiere.
Ich meine, man wird dann ja auch schlechter,
aber man lernt das dann ja.
dass man halt rumschlampt und so.
Und das ist eigentlich alles, das will man einfach alles gar nicht,
sondern man möchte eigentlich mit weniger Zeit mehr hinbekommen.
In der Umschlammschule, man lernt rumzuschlammen.
Und Tests lösen das.
Ja, ich meine, die Frage ist halt auch, was man für einen Anspruch hat
oder was der Lebenszyklus der Software ist.
Also als wir noch ganz klein waren, da haben wir dann öfters mal so Marketing-One-Pager gemacht,
keine Ahnung, Kaugummi-Werbung und sowas.
Das ist so ein Ding, da ist ein Gewinnspiel drin, das läuft genau für einen Monat
und danach wird das Ding eingestampft und es braucht kein Mensch mehr.
Ja gut, klar.
Das sollte natürlich trotzdem funktionieren.
Das merkt man ja beim Angucken schon fast, wenn man einfach Localhost aufmacht.
Aber wenn man halt sagt, hey, das ist irgendwie jetzt vielleicht was, was firmenstrategisch relevant ist,
da committet sich die Firma auch ein bisschen drauf, dass jetzt vielleicht auch über Jahre,
dass sie da halt irgendwie investiert hat und das muss gut laufen.
Ja, also ich meine, bei den Projekten, die wir jetzt lange betreuen
und die wir damals auch ohne Tests angefangen haben,
ziehen wir die jetzt auch einfach nach.
Weil ich meine, das ist halt einfach sinnvoll.
Und man kann inzwischen …
Macht ihr das dann auf eigene Kosten
oder sagt dann der Kunde,
ja okay, das ist jetzt hier in unserem Supportaufwand das …
Wir machen das eigentlich so,
dass wir jetzt halt sagen,
die Tests sind ein elementarer Teil der Programmierung.
Ja.
Also das ist halt so,
als ob man sagt …
Zehn Minuten aus einer Stunde nur für Tests oder so.
Ja, ich würde sagen, wie gesagt,
also ich bin jetzt auch keiner,
der sagt, coverage 100 Prozent,
weil wie gesagt, ich glaube einfach 80-20-Regel,
ich glaube in 80% der Zeit,
also 80% des Notwendigen
kriegt man in 20% der Zeit hin.
Und keine Ahnung, wenn ich da irgendwelche
Django-Views oder sowas habe, die mehr oder weniger einfach
getestete Django-Funktionalität ausführen,
schreibe ich keinen Test dafür.
Wenn ich irgendwelche Permissions drin habe, an denen ich selber rumgebastelt
habe, okay, das ist was anderes,
weil das kann echt mal schnell in die Hose gehen.
Aber so Standard-Funktionalität
teste ich jetzt auch nicht unbedingt.
Also umso mehr es Richtung Zahlen und Details
und Services geht, also weiter weg
von dem Django-Standard.
Übrigens interessant, wir reden gerade
die ganze Zeit nur von Django, also Testing kann man ja
auch außer von Django tun. Das stimmt. Aber wir
machen halt einfach viel Django, deswegen reden wir jetzt erstmal weiter über
Django-Tests. Aber ich meine, die meisten
Sachen sind ja universal.
Also ist ja jetzt nichts
Django-spezifisches, also selbst bei
Flask gibt es Views.
Ja, und eigentlich hat man
bei jedem Projekt, also es sei denn, man macht halt
irgendwas, was halt tatsächlich nicht so einen
wichtigen Anwendungsfall hat, aber
eigentlich hat man immer Tests mit dabei.
Und auch bei Django ist genau das, was man halt sonst verwendet,
irgendwie üblich, nämlich entweder das
eingebaute Unit-Tests-Modul
aus der Standardbibliothek oder halt eben
PyTest, wobei
ich sagen würde so,
wenn ich mich so umgucke bei den Projekten,
in denen ich irgendwie beteiligt bin,
ist die Mehrheit inzwischen auf PyTest
und Unit-Test fühlt sich so ein bisschen an,
als das sind immer so die etwas älteren Sachen
und die etwas nicht so ganz gut gepflegten.
Und ich meine, natürlich hat das irgendwie
gewissen Charme, dass das...
Vielleicht, erklär mir doch mal kurz, was denn überhaupt der Unterschied ist
zwischen Unit-Testers und was PyTester neu herumbringt.
Und es gibt auch einen Nose-Tester oder sowas.
Ja, Nose
war früher ein Test-Runner.
Ich glaube, das ist inzwischen gar nicht mehr wirklich
Main-Tent.
Ich habe gehört, Johannes benutzt noch viel Nose.
Ernsthaft? Okay.
Vielleicht bist du ja auch Unit-Tester, ich weiß nicht.
Er möge mich schlagen, wenn er das hört.
Ja, keine Ahnung.
Also Nose kenne ich auch noch, aber das ist schon echt lange her.
Also aus meiner Perspektive
ist es, also
Unit-Test ist irgendwie eine Portierung von
JUnit und hat halt
viele der Konzepte dort mitgebracht,
die ja auch jetzt vielleicht gar nicht so schlecht sind, aber
das passt halt in vielen Fällen nicht so
richtig auf das, wie man in Python normalerweise
programmiert. Was heißt das denn?
Also was macht JUnit und warum
ist das so anders als das? Ja, zum Beispiel
einfach allein, dass die Methoden am CamelCase sind.
Ja, okay. Dann,
dass du halt
Assert-Methoden hast auf dem Test,
dass jeder Test eine Klasse sein muss.
Das ist halt, also ich meine.
Wie testet man überhaupt?
Also man macht eine Testklasse und da setzt man quasi die Umgebung auf
und dann prüft man, ob bestimmte Bedingungen erfüllt sind
und dann baut man alles wieder auseinander.
Ja, also wenn man jetzt so, wie Schreib- und Tests kommen,
also da ist es halt, nennt man das so AAA, wie heißt das, Range?
Ich glaube, wo ist das Intent, wenn man es braucht?
Oder sowas und Assert oder weiß ich nicht.
Also man arrangiert sozusagen die Dinge, die man halt, die Welt sozusagen so hinten, dass man testen kann.
Dann ruft man halt die Funktion, die man testet, auf oder halt was auch immer man da testen möchte.
Und dann guckt man hinterher, ist jetzt alles in sozusagen gefälliger Weise wieder drüber zerfallen.
Und es ist so passiert, wie es hätte, wie ist der sozusagen Schornstein in die richtige Richtung,
der Baum in die richtige Richtung umgefallen sozusagen nach dem, ja.
Und das macht man halt
bei Unit-Tests in der Klasse.
Die Tastic-Testcase, ich glaube, Django-Testcase
erbt auch von den Unit-Testcase, oder?
Ja. Also es gibt bei Django
vier Testcase-Klassen,
aber ich glaube,
die erben alle
von Testcase, ja.
Genau, bei PyTest ist es so,
da können auch Tests einfach Funktionen sein
und das ist halt nicht Camel-Case,
sondern Snake-Case oder keine Ahnung,
mit Underscores halt.
Und man verwendet halt nicht
Methoden auf dem Test, um zu testen,
um zu asserten, sondern
man benutzt einfach das Assert-Statement.
Das macht PyTest ja jetzt auch dann.
Das macht PyTest.
Unitest macht das nicht.
Also bei Unitest gibt es mal diese Assert-Equals, das hat mich immer so ein bisschen gewundert.
Ja, genau, genau. Assert-Equals,
super, super Beispiel, genau.
Wisst ihr das, was die richtige Methode ist? Assert-Equals
oder Assert-Equal? Ich glaube ohne S, oder?
Ja, siehste,
weiß ich jetzt auch gar nicht.
Eins von beiden ist richtig, das andere ist nicht gut.
PyCharm zeigt mir immer an, dass, glaube ich, das mit S,
das ist immer durchgestrichen wegen Deprecation.
Ja.
Assert-Equal.
Eins von beiden ist deprecated, genau.
Aber das ist halt so, das ist halt das Problem,
das man bekommt, wenn man halt so Spezialkram macht.
Ja, das versteht man auch nicht.
Warum kann man nicht einfach die Python-implementierte Funktion
Assert nehmen und dann die zwei Dinge direkt vergleichen,
anstatt Assert-Equal hinzuschreiben und zwei Dinge
in diesem Funktionsaufbruch zu gehen?
Da passieren irgendwelche magischen Dinge im Hintergrund,
wo ich gar nicht weiß, ob das so stimmt.
Ja gut, wenn du sozusagen bestimmte Sachen
mit einem gefällten Test machen willst oder so,
dann kannst du das ja quasi gar nicht
so richtig gut anders machen, oder?
Ich weiß es nicht, vielleicht ist es auch einfach nur Geschmacksgeschichte.
Wie ist das denn
mit zum Beispiel den anderen Asserts,
zum Beispiel AssertRaises?
Kannst du das auch über das AssertStatement
abbilden bei PyTest?
Ja,
aber es kann sein, dass man...
Also wenn man jetzt Tests zwar accept Asserts und AddRaises...
Nein, nein, aber es kann sein,
also es ist auch ein ContextManager,
es ist irgendwie With irgendwas, Raises,
Aber ich glaube, man importiert da irgendwas
dann aus PyTest. Also der Hintergrund ist
ja einfach nur, dass falls jemand,
falls eine Funktion Fehler werfen soll und man
genau diesen Case testen möchte.
Ja, also das gibt es auf jeden Fall.
Ich muss gestehen, ich nutze auch das, was
Django von Haus aus mitbringt.
Ich habe da, ich habe einen Kollegen,
der sehr auf PyTest schwert und meint, das ist ja alles
viel besser und schneller. Ich habe das auch
auf meiner Liste, dass ich mir das nochmal anschaue.
Ja, es
ist halt sehr convenient, wenn du halt in der
Django-eigenen Welt bleibst, dann
muss man halt wenig
nachdenken. Von Jochen jetzt
PyTest irgendwie gelernt.
Modus hast du mal vier und da gibt es halt
diese Features. Gibt es die auch so
bei
Unit-Tests ohne PyTest? Also ich dachte, das wäre
so ein PyTest-exklusives Feature. Also in Django
kannst du es laden. Also in Django gibt es
in dieser Django-Test-Case-Klasse kannst du
einfach
ein Array mit Strings
und diese Strings sucht er dann,
der sucht dann nach
Fixture.json-Dateien.
Okay, aber ich mache tatsächlich Fixture.json und ich muss
halt dann dadurch meine Sachen... Genau, aber das ist jetzt nur
Django, das ist nicht Unit-Test. Also ich weiß nicht, wie
ein Test das machen würde. Also ich kenne das
als PyTest, dass ich tatsächlich meine Fixture-Funktionen baue
in der Comptest und dann irgendwie
meine Objekte schon so erzeuge,
wie sie, glaube ich, im
echten, realen Django-Leben
dann auch wären.
Und das hat vielleicht auch viele Vorteile,
weil ich halt genau auf die Attribute und so weiter alles zugreifen kann
und ich dann halt Factories nutzen kann, um die zu erzeugen
und halt eben nicht nur irgendwie
Fixtures? Also das macht man im Unit-Test
auch. Also so Factory-Boy oder
Factories, um halt
aber, ja, aber diese Art,
wie man in Pytest halt, dass man das
quasi einfach magisch, dass man das halt
in den Testaufruf
mit reinschreibt halt, das man haben möchte und es ist
dann halt einfach da. Das ist auch so natürlich
ein bisschen magisch. Das gibt es im Unit-Test nicht.
Da muss man es explizit machen.
Okay, ja, aber das finde ich eigentlich relativ smart, weil das
gefällt mir. Ich kann einfach meine Fixtures definieren pro
App, die ich dann irgendwie entwickelt habe und
dann kann ich die importieren in anderen Apps als
Confest und habe dann alle Funktionalitäten
nicht, da brauche ich irgendwie... Ich löse das halt über
Vererbung, also ich habe halt dann einen Basetest, der
dann halt für mein Projekt halt irgendwie die Rollen,
die User, vielleicht
irgendwie ein wichtiges Projekt oder irgendwas
erstellt und dann halt
pro App, dass ich dann halt,
wenn ich das brauche, dann nochmal
eine Ebene dazwischen ziehe und dass dann jeder
von den richtigen Tests, also
die Endtests,
dass die halt dann von dieser Klasse erben
und da ist dann das dementsprechende Setup
im Setup drin.
Das heißt, ich nutze diese Django-Fixers auch eher selten.
Ja, genau. Ich habe auch viel, also im Projekt mit Unitest, dass ich dann halt so viele Test-Mix-Ins importiere oder das habe ich halt früher immer gemacht dann, die dann halt bestimmte Funktionalität bieten.
Und was ich jetzt aber inzwischen so mache, ist, ich erbe von Testcase oder halt Transaction Testcase oder was auch immer, also einem der Grundtesttypen von Django und mixe die Sachen dann da schon mal rein und verwende dann nur noch meine eigenen Testcases.
Und sozusagen habe dann die ganzen Importe nicht mehr in den Tests stehen, sondern ich sage dann halt irgendwie, keine Ahnung, nimm halt den App-Test-Case von irgendeiner App und da sind die ganzen Mix-Ins dann halt drin.
Und genau, dann ist es halt deutlich weniger Schreibarbeit.
Ja, das sieht auch hübscher aus, glaube ich. Also ich habe, glaube ich, eine Sache gemacht, ich weiß nicht, ob man diese macht.
Ich habe dynamische Importe gemacht für Tests von den Factories, die ich dann halt haben wollte in der Core-App, weil ich halt nicht genau weiß, wie viele Apps gibt es denn noch um die Core-App herum.
Ich weiß nicht, ob das so eine gute Idee ist, aber das funktioniert bisher.
dynamische Importe klingen zu müssen.
Ja, naja.
Ich meine, manchmal muss man auch Sachen ausprobieren und manchmal sind sie
super. Wenn man stellt irgendwann fest,
war nicht so gut, muss man es wieder ändern.
Aber es ist halt, ja.
Ja.
Was ja fast
schon ein Stichwort wäre zum... Ja, dynamische,
genau. Zum Sachen ausprobieren.
Ich hatte
vor einiger Zeit
habe ich eine Django-Software
gebaut. Da ging es um
Projektstundenerfassung und Zeiterfassung.
Und alles, was irgendwie mit Daten, also Datums, also mit Zeit zu tun hat, ist ja schon relativ kompliziert. Und da ging es dann darum, dass halt eine Zeiterfassung abgebildet werden soll.
Also Mitarbeiter können sich an und aus checken und dann gibt es natürlich so Späße wie jemand ist krank, jemand ist im Urlaub, es gibt einen Feiertag, es gibt halbe Feiertage, zum Beispiel Weihnachten und Silvester, also Heiligabend und Silvester sind halbe Feiertage, das heißt man hat, also wird je nach Firma anders ausgelegt, aber in dem Fall war das dann vier Stunden das normale Arbeitszeit wäre.
Und die ganze Logik lief und hat auch gut funktioniert. Da habe ich immer gemerkt, wenn ich irgendwas refactoren möchte, ich hatte jedes Mal die Hosen voll und habe mich halt wirklich nicht daran getraut, weil das halt einfach so unmöglich zu testen ist. Und habe dann erst mal angefangen, ganz normal zu Fuß Tests zu schreiben, also einfach zu schauen.
Und ich habe, ich setze den und den Case auf, also keine Ahnung, Mitarbeiter arbeitet normal fünf Tage die Woche, also diese ganzen Datenbankobjekte erstellt und habe gemerkt, da komme ich echt irgendwie nicht weit. Das sind so viele Fälle und auch immer diese ganzen Variationen. Was ist denn, wenn jemand zum Beispiel Teilzeit arbeitet und dann kommt ein Feiertag und dann vielleicht noch ein halber Feiertag und ja.
Ach, ist ja ausgefallen, da ist die Vertretung und die Vertretung übernimmt dann aber noch anderthalb Tage, weil dann den halben Tag eine andere Vertretung dann reinkommt.
Genau. Und dann habe ich angefangen, eine abstrakte Testklasse zu schreiben, die im Endeffekt alle Testmethoden implementiert.
Und die quasi, diese Berechnung, also diese Zeitenberechnung, habe ich im Endeffekt nochmal abgespeckt, nachprogrammiert in dieser abstrakten Testklasse.
Und diese abstrakte Klasse wird befüttert durch ein Dictionary von Objekten. Und diese Objekte, die sind zum Beispiel, der eine Mitarbeiter arbeitet ganz normal acht Stunden und macht so lange Pause. So, das ist ein Objekt, das da reingehen kann. Der andere ist zum Beispiel ein anderer Mitarbeiter, der ist nur halbtags da und der arbeitet diese, seine halbtags, also seine vier Stunden arbeitet der auch voll.
Oder es ist ein Wochenendtag.
Und ich konnte dann, wenn ich dann einen aktuellen, also einen tatsächlichen Test schreiben möchte, leite ich davon ab.
Da sind gar keine Testmethoden in dieser Kindklasse drin, sondern ich befülle nur dieses Dictionary, diese Klassenvariable und gebe da eine Liste von Objekten rein.
Sag zum Beispiel, okay, ich weiß der, keine Ahnung, 1.1.2017, 2017 habe ich es gemacht, darum, das war jetzt ein Sonntag.
Das heißt, da gebe ich das Objekt rein, ist normaler Wochenendtag, da hat niemand gearbeitet. Am Montag kommt das Objekt rein, alle arbeiten normal und dann vielleicht die ganze Woche voll und dann schaue ich einfach, ob zu erwarten ist, dass niemand, also alle haben normal gearbeitet, dass es null Überstunden sind.
Das macht dann aber wieder die abstrakte Klasse. Und das heißt, für jeden Testfall, den es gibt, also alle komischen Kombinationen, kann ich einfach diese Objekte befüllen. Und wenn ich jetzt einen neuen Testfall habe, muss ich entweder nur diese Liste neu zusammenstellen oder halt ein neues Objekt bauen, das halt die Sachen so einstellt, dass es funktioniert.
War ziemlich abgefahren, ich habe auch ziemlich lange dafür gebraucht. Im Endeffekt war es ziemlich cool, weil jedes Mal, wenn ich einen Bug gefunden habe, konnte ich halt in drei Minuten, also literally drei Minuten, halt einfach diesen Fall nachstellen mit meinen ganzen Objekten und konnte sicherstellen, dass es beim nächsten Mal nicht mehr kaputt geht.
Die größte Herausforderung dabei, und das ist auch so ein bisschen das große Fragezeichen dahinter, ist halt, wer kontrolliert den Kontrolleur? Weil ich habe ja den Code nochmal teilweise nachgebaut. Also ich habe ihn jetzt explizit nicht kopiert, sondern ich habe ihn neu geschrieben und auch ein bisschen abgespeckt.
Aber was ist, wenn man jetzt einen Bug im Testcase hat?
Und tatsächlich, glaube ich, 80 Prozent der fehlgeschlagenen Tests
lagen daran, dass ich in der Nachimplementierung einen Bug hatte.
Ich glaube, ich hatte eine richtige Implementierung,
die ich damals noch vor vielen, vielen Jahren ohne Tests geschrieben habe.
Da war tatsächlich auch kein Fehler mehr drin,
weil es halt schon so lange lief und die alle ausgemerzt waren.
Ich war mir sehr unsicher,
ob das überhaupt eine gute Idee ist, das so zu machen,
wegen der offensichtlichen Nachteile, die es halt gibt.
Also dauert lang und wer kontrolliert das nachher?
Oder wie kontrolliert man das?
Und habe dann auf dem PyCologne Meetup, zufällig war da jemand, der mehr oder weniger in einer großen Firma genau sowas macht für sehr komplizierte Fälle.
Ich glaube, das war medizinischer Bereich, wo es halt wirklich stimmen muss.
Und der meinte, wenn es wirklich, wirklich kompliziert ist, dann geht es nicht anders.
Also die meinte, es gibt sogar Software, die so kritisch ist, dass die einfach den Auftrag, das gleiche Pflichtenheft an zwei verschiedene Teams geben, die sich nicht kennen.
Lass uns beide programmieren und das eine ist halt das Testsystem vom anderen.
Ja, also es ist schon absurd.
Das ist ja Mocken auf einem ganz hohen Niveau.
Ja, das ist, ich meine, das ist ja auch immer die Frage, wie aufwendig ist es halt, irgendwas zu ändern.
Also wenn man jetzt, ich meine, die Prozessorhersteller machen das ja auch,
dass sie halt irgendwie wahnsinnig viele Tests machen, dann Stresstests irgendwie für neue Designs von ihren Chips und so
und versuchen das letzte bisschen, was überhaupt testbar ist, da rauszukitzeln.
Einfach deswegen, weil wenn die Maschinen erstmal eingestellt sind und die Wafer irgendwie belichtet,
dann ist halt schlecht, wenn das irgendwie schiefgegangen
ist, weil man kann man auch nicht
mehr ändern, kann man halt hinterher nicht mehr fixen
während, naja, Code kann man halt noch
ändern, das heißt so
furchtbar intensiv muss man es vielleicht auch nicht testen
aber natürlich
ist es halt immer noch blöd, wenn Sachen schief gehen
daher, ja, irgendwo ist da ein Sweet Spot
aber ist halt nicht so ganz klar, wo
testen ist ja schon ein bisschen
dunkle Magie auch, also ich hatte
das Problem, ich habe einen Test geschrieben
dann habe ich die Tests
ausgeführt, dann
war kein Problem mehr, alles richtig, dann habe ich es nochmal
ausgeführt, einfach ohne irgendwas zu ändern und dann
schlug der Test fehl.
Was ist denn das jetzt?
Habe ich nochmal ausgeführt, dann ging es wieder,
dann habe ich nochmal ausgeführt, dann ging es wieder, dann habe ich nochmal ausgeführt,
dann schlug es wieder fehl. Dann hat mir jemand erklärt,
ich habe einen non-deterministischen Test geschrieben,
also einen Test, der in Ausgang ungewiss ist.
Und ich habe überhaupt nicht verstanden, von welchen
Zeiteffekten, von welchen
Gegebenheiten das hätte kommen können.
Das fand ich total schwierig zu begreifen,
warum der gleiche Test in
mehrfacher Ausführung mal B-Check, mal nicht.
Ja, das Ganze gibt es dann natürlich auch irgendwie in sozusagen Reihenfolgenabhängigkeiten, das ist wahrscheinlich somit das Häufigste, dass man quasi zwei Tests hatte und da, ohne dass man das jetzt beim Schreiben vielleicht so gedacht hätte, man macht es halt einfach so, weil das dann halt logisch hinterher passiert oder so, man macht zuerst das, dann testet man das nächste und verändert aber den State jetzt bei einem Django-Modell irgendwie so, dass der zweite Test halt funktioniert und wenn man jetzt die Tests in umgekehrter Reihenfolge ausführt, dann funktioniert das nicht mehr.
Und das ist halt auch so ein Ding. Man muss halt eigentlich sicherstellen, dass die ganzen Tests isoliert funktionieren, weil ansonsten kann man nämlich...
Da gibt es ein sehr schönes Beispiel, das ist auch ganz brandaktuell zu Django 3.1. Die haben da jetzt nämlich einen Bug gefixt, der schon, glaube ich, seit 2012 drin war, mit dem Order-By beim Aggregate. Ich weiß nicht, ob euch das mal über den Weg gelaufen ist.
Ist mir am Anfang, als ich neu mit Junko war, immer wieder mal passiert, dass, ich bin mir nicht mehr so 100% sicher, ich habe es länger nicht mehr selber erlebt, aber wenn man eine Aggregierung oder ein Annotate macht und dann Order Buy, beziehungsweise nein, wenn das Model selbst in der Meta-Option, in Order Buy, der so eine standardmäßige Notierung aktiv hat, dann gab es Bugs.
dann hat das ORM teilweise komische oder falsche Sachen zurückgegeben.
Das ist wie der Bug, das Ticket ist 3000 Jahre alt
und die haben das jetzt tatsächlich repariert
und das führt dazu, dass die Lösung war einfach,
das ist halt aus Gründen, funktioniert es nicht
und das heißt, wenn du aggregierst oder annotierst,
dann wird dieses Order By im Model Meter ignoriert.
Das heißt, bei meinen Cases, wo ich das gemacht hatte,
habe ich in meinen Test Cases natürlich erwartet,
dass die Sachen sortiert kommen, weil ich ja wusste,
meine Projektliste oder meine Mitarbeiterliste,
die wird ja
übers Model sortiert. Hatte ich natürlich
kein explizites Order bei gemacht.
Plötzlich schlagen irgendwelche Tests fehl, nachdem ich auf
Django 3.1 hochgegangen bin, weil die Reihenfolge anders ist.
Weil es gibt jetzt kein Order bei mir. Es gibt halt irgendeine
Reihenfolge, die die Datenbank zurückgibt.
Okay, ja, das ist
aufgefallen, ja. Ziemlich abgefallen.
Ich habe auch erst gedacht, das kann doch nicht sein.
Ich habe Django hochgezogen, was ist denn da los?
Bis mir dann ein
lieber Kollege sagte, schau mal,
Such mal nach Order-By in den...
Also Order-By ist echt rausgeflogen?
Nee, das ist nur für diesen Sonderfall.
Das war ein Bug und den haben die jetzt rausgenommen.
Also den haben die gefixt und die Lösung dafür ist,
dass es halt nicht mehr genommen wird.
Du kannst es manuell dahinter schreiben, dann funktioniert es.
Aber du musst es halt manuell machen.
Aber in der Meta-Klasse geht es nicht mehr?
Immer, außer du machst Annotated Aggregate.
Ah, okay.
Da gibt es auch einen eigenen Eintrag dazu.
Das ist auch irgendwo im Ticket nochmal festgehalten und verlinkt etc.
Ich bin da jetzt auch nicht 100% in Details drin.
Ich bin halt nur drüber gestolpert.
Weil das war auch genau das mit der Reihenfolge. Plötzlich war mein Element, dass ich an Stelle 1 erwarte, an Stelle 2 und umgekehrt. Und wenn man halt die Tests so gebaut hat, dass der halt die Reihenfolge explizit erwartet, weil ich ja wusste, dass er damals noch sortiert war, dann steht man da plötzlich.
Ja, und das mit der Reihenfolge von Tests ist halt…
Und das ist halt auch deswegen so wichtig, weil nämlich ein Feature braucht quasi die Isolation, also dass halt alle Tests einzeln isoliert voneinander sind und nicht abhängig von irgendwelchen anderen Tests sind. Und das ist nämlich, dass man die Tests, wenn man die Tests parallel ausführen möchte, dann müssen die so sein, weil ansonsten kriegt man halt ein Problem.
Und da gibt es dann halt auch, ich weiß nicht, ich glaube, da muss man irgendwas installieren, ich weiß es nicht mehr so genau. Also man kann auf jeden Fall, und ich weiß auch nicht, das ist bei PyTest und bei Unitest anders, aber man kann halt mit einer bestimmten Option sagen, so für die Tests mal eine umgekehrte Reihenfolge aus. Wenn das schief geht, dann weiß man schon, dass man ein Problem hat. Oder für die mal eine zufällige Reihenfolge aus, dann muss man es halt wahrscheinlich ein paar Mal ausführen und wenn es dann funktioniert hat, hat man vielleicht Glück gehabt und man kann es parallelisieren.
Aber genau, wenn die Tests isoliert voneinander funktionieren, dann kann man halt die halt auch parallel ausführen und dann halt es halt quasi um den Faktor, wie viele CPUs man halt hat, beschleunigen. Und das ist natürlich auch sehr nett, weil ich meine, ja.
Und wir haben heute nicht schon ganz, ganz viele CPUs zur Verfügung.
Genau, ja.
Ja, es gibt sogar noch ein Ding, Xist oder so,
mit dem kann man dann halt Sachen noch auf mehrere Rechner verteilen.
Aber ein Rechner ist ja schon mal nicht so schlecht.
Wenn man da so acht Cores hat,
dann geht das schon mal deutlich schneller,
wenn man die alle verwenden kann.
Aber wenn man eine große Basis,
ein Projekt hat mit vielen Tests, Testbasis,
und die sind nicht unabhängig voneinander,
dann kann man das mit dem Parallelisieren eigentlich fast vergessen,
weil das kriegst du halt nicht so einfach umgestellt.
Ja.
Ja, genau. Wie ist das? Habt ihr da häufig Probleme mit langlaufenden Tests?
Wie viele Tests habt ihr denn überhaupt? Bei großen Projekten muss das ja in die Zehntausende gehen.
Ja, tatsächlich. Also bei unseren langlaufendsten Projekten bin ich nicht mehr aktiv dabei.
Also bin ich nicht im Dev-Team, das heißt, ich habe da jetzt keine Zahlen, aber ich weiß, dass die Pipelines da teilweise auch Stunden brauchen. Also einfach, weil, also die haben da inzwischen noch Optimierung gemacht.
Das kommt ja gar nicht nach jedem Feature Release, wenn man da irgendwie Agile irgendwie dran sitzt.
Natürlich haben wir da jetzt auch Lösungen irgendwie gebaut, dass halt manche Tests laufen dann irgendwie nicht mehr pro Commit oder irgendwie Sachen werden lokal getestet, weil es lokal doch manchmal ein bisschen schneller geht oder es ist eine Parallelisierung.
Bei dem längsten Projekt, das ich betreue, das ist eine Internet-Software, da habe ich jetzt die 1200, glaube ich, geknackt. Ja, und das ist ganz lustig. Ich hatte da, ja, das waren ungefähr, ja, also in der Pipeline lief das immer so 25 Minuten, die Tests.
vertretbar ist, aber es hat mich trotzdem immer ein bisschen geärgert
und
habe ich irgendwann mal einen Artikel
auf Medium gefunden, wo jemand meinte,
ja, wenn man die Tests ganz
klassisch mit Setup geschrieben hat, dann
das geht besser,
weil bei dem Setup, also wir reden jetzt wieder vom
Django-Unit-Test-Welt und ich glaube, das ist insgesamt
Unit-Test-Welt, beim Setup ist es halt so,
dass halt vor jeder Testmethode alles, was im Setup
steht, ausgeführt wird und es gibt
eine Klassenmethode,
die halt quasi nur einmal pro
Testklasse ausgeführt ist, also hat eine Testklasse
jetzt hier einen Test, dann wird es halt nur einmal ausgeführt, bei Setup
wird es jedes Mal ausgeführt und Django hat halt
so eine magische Funktion, das nennt sich
SetupTestData und
da wird es
in eine Transaction
gerappt, das heißt
die Daten werden nur einmal ausgeführt,
also es ist auch eine ClassMethod, also es ist nur einmal pro Klasse,
aber die kann man quasi recyceln,
also bei jedem
Testaufbau, das heißt man hat so ein bisschen das Beste von beiden
Welten. Ich habe das dann gelesen, fand das cool
und dachte, ach mal gucken, was das bringt, habe gedacht,
1000 Tests, das dauert bestimmt ewig,
Aber tatsächlich ging es relativ fix. Nach zwei, drei Stunden war ich fertig. Und ja, habe die Pipeline von 25 Minuten auf fünf Minuten gedrückt für die Tests. Und das hat mich halt echt richtig, richtig, richtig überrascht, dass das so viel bringt tatsächlich. Ich meine, klar, wenn man überlegt, dass jede Testklasse vielleicht 20 Tests hat, dann, ja, fünf Tage schneller.
Da gab es doch jetzt auch genau dieses Buch dazu,
wie man Django-Tests...
Ja, von Adam Johnson, jetzt irgendwann im Mai rausgekommen.
Speed Up Your Django-Tests
heißt das irgendwie.
Genau, und
da, ich habe es nicht ganz
komplett gelesen, ich habe so ein bisschen, also ich habe es
auch so ein bisschen quer gelesen schon, aber noch nicht so.
Ja, da stehen viele, viele
coole Sachen drin, also auch ganz...
Das sagt der Jochen erst wieder, weil der ist Glossar noch nicht bis zum letzten Mal.
Nein, ich habe es wirklich, ich habe
ein ganzes Kapitel noch gar nicht gelesen.
Aber da stehen auch viele interessante Dinge drin.
Also zum Beispiel, dass man halt, ja, also auch im Vergleich Unitest, PyTest zum Beispiel,
der sagt da halt auch, ja, PyTest ist eigentlich schon cooler.
Bei vielen Kapiteln steht dran, so, das ist jetzt nur für Unitest relevant,
bei PyTest muss man das nicht machen, da ist das schon richtig so von Natur aus sozusagen.
Und der schreibt auch, ja, PyTest ist ein Stück schneller.
Es ist auch so, wenn man das zum Beispiel, sowohl PyTest wie Unitest geben ja aus, wie lang sie laufen.
Aber Unitest ist so ein bisschen gemogelt.
Also viele Sachen kommen da nicht mit rein, da muss man halt, also auf dem Unix schreibt man halt Time davor, um halt zu sehen, wie lange hat es denn wirklich gedauert und tatsächlich die Real Time, wie lange hat das gedauert, ist halt das, was einen eigentlich interessiert und da ist PyTest schon normalerweise ein Stück schneller und bei der reporteten Zeit ist es relativ ähnlich, aber das liegt halt daran, dass PyTest einfach mehr Sachen dazu zählt, zudem, dass halt jetzt so lange hat der Test gedauert.
Ja, also was er empfiehlt, was man halt am Anfang machen kann, ist, also man sollte erstmal messen, also halt zum Beispiel sich anschauen, was sind denn eigentlich so die langsamsten Tests, die man so hat, weil normalerweise hat man da auch so eine Pareto-Verteilung, dass halt 20% der Tests machen halt 80% der Zeit aus.
Und mit Pytest geht das einfach so mit Minus-Minus-Durations und dann eine Zahl und dann kriegt man halt die Zahl langsamsten Tests einfach am Schluss ausgegeben und bei Unit-Tests muss man halt irgendwie Django-Slow-Tests installieren oder so.
Aber damit geht das dann auch und dann den Test-Runner ersetzen und dann kriegt man die halt auch ausgegeben und dann kann man halt bei den Tests halt mit einem Profiler nachgucken, was macht die eigentlich so langsam und dann findet man wahrscheinlich schon Dinge, die man halt verbessern kann.
Und ja, da gibt es dann auch so Dinge wie, ja, man kann halt, es gibt diverse Tools, mit denen man sich dann, man kann ein C-Profile, kann man Ausgaben an Zeugen, wie man sich dann gucken kann, mit K-Cache-Grind oder, naja gut, muss man sich, da gibt es eine Menge Zeugs.
Dann gibt es so Easy-Wins, so einfache Dinge, die man halt mal tun kann, um halt die Geschwindigkeit von Tests zu verbessern.
Und da ist, glaube ich, das Erste, was er schreibt, ist halt den Passwort-Hasher zu ersetzen.
Das ist halt auch mal so ein Standard, weil man erzeugt halt viele User und so.
Und die echten Passwort-Hash-Algorithmen sind natürlich extra so designt, dass sie möglichst langsam sind,
damit man halt nicht viele Hashes durchprobieren kann, weil es einfach zu teuer wäre.
Das will man jetzt natürlich, wenn man Sachen beschleunigen
möchte, möchte man nicht. Man möchte es halt aber eher
schnell haben. Und dann, wenn man dann den MD5
Hasher nimmt oder so, der ist halt nicht sicher, aber
der ist halt egal.
Bei der Test ist es halt egal, weil da kennt man die Passwörter
ja eh, die man da hasht. Das würde man dann
über eine Mock-Funktion wahrscheinlich machen, oder?
Nee, das kann man einstellen. Das ist ein Setting.
Du kannst die Middleware einfach in den Settings testen.
Kannst du die Middleware dann einfach...
Nee, das ist keine Middleware. Du kannst den Passwort
Hasher setzen. Ja, okay.
In den Settings. Du sagst dann halt nicht
Passwort Hasher
irgendwas von den, importierst halt
deinen MD5-Password-Hasher oder schreibst halt
den String zu dem
Hasher einfach in die Config rein.
Fertig. Ich meine, rein theoretisch braucht man auch gar keinen
Password-Hasher. Ich meine, du willst dich ja nicht einloggen in Tests.
Ja. Ja.
Ja, keine Ahnung. Ich weiß nicht, es wird halt empfohlen,
den MD5-Dings zu nehmen. Keine Ahnung, warum.
Vielleicht hat das auch noch irgendwelche Seiteneffekte. Ich weiß es nicht genau.
Wenn man jetzt da sagt, gar nichts, ob das irgendwas
ändert. Ich weiß es nicht.
Auch noch nicht gemacht. Keine Ahnung.
Genau, das war so
das ist so das Erste, was er empfiehlt.
Dann sagt er sowas wie
ja, irgendwie
die, vor allen Tests wird irgendwie
die Datenbank serialisiert.
Man kann jetzt an den Datenbank-String ranschreiben,
also für die Test-Datenbank
serializable
Doppelpunkt false oder so, auch eine Config-Option
und dann wird das halt nicht gemacht.
Man braucht das eigentlich fast nie. Es gibt ganz selten
Testfälle, die sowas benötigen, aber
eigentlich braucht man das nicht und
macht auch Sachen schneller.
Und dann, was war da noch drin? Also solche Dinge, wie man kann, das kannte ich gar nicht. Also das war mir neu. Ich habe tatsächlich, oder ich weiß nicht, wie du das machst mit Files, wenn du halt irgendwelche Bilddaten oder so testest oder so, da hat man ja auch viel mit Files zu tun.
Ich hatte zum Beispiel immer das Problem, dass dann halt viele Files einfach noch am Schluss rumgelegen sind und dann habe ich halt irgendwelche Dinger geschrieben, nicht Clean-up-Scripts, sondern halt schon das quasi so mit in die, ich habe dann das in Dekoratoren reingeschrieben und dann halt die Testklassen dekoriert und die haben dann hinterher quasi das Media-Root wieder aufgeräumt oder so.
Ich weiß gar nicht mehr genau, wie ich das gemacht habe.
Aber auf jeden Fall habe ich da halt irgendwie
Aufwand reingesteckt und dachte so, das war ätzend.
Und es gibt
DJ-In-Memory-Storage, heißt das Paket,
glaube ich. Und da kann man
das Default-Storage
ersetzen durch halt In-Memory-Storage.
Und dann wird überhaupt nichts gespeichert.
Und das ist halt viel schneller, weil es ist halt In-Memory.
Es funktioniert halt genauso, aber
es landet hinterher gar nichts auf der Platte.
Und wenn man viel mit Files macht,
dann ist es halt sofort deutlich schneller.
Ja,
Das fand ich echt gut.
Das ist sehr praktisch.
Dann gab es noch so
Celery-Optimierungen. Da kann man auch
ein Memory-Backend verwenden.
Und naja, man muss halt
gucken, dass man halt
Always-Eager auf True setzt und
auch noch irgendwas anderes, weiß ich nicht mehr genau.
Ja, sowieso
diese ganzen Async-Task-Dinger.
Da gibt es dann halt Jungle-Queue.
Das will ich mir mal angucken. Celery habe ich
letztens wieder. Ah, Celery!
Ja, genau.
euch vielleicht auch, mich hat es auf jeden Fall
vor ein paar Tagen ein bisschen mal wieder
als ich irgendwie
dachte so, irgendwie
seltsam ruhig hier so alles
irgendwie, passiert da zu wenig
auf dem Produktionssystem, wie kommt denn das
und ich hatte gerade irgendwie released
und guckte dann halt so in die Logfile und denke so
was ist mit den ganzen Sanitars
warum, wie, wo sind die
wieso, was
warum werden da keine Sanitars mehr ausgeführt
und dann habt ihr so ein bisschen gegoogelt
und dann ja, ich glaube 4.4.7 war das
oder so, hat irgendeine Regression,
böse Regression drin gehabt, dass halt die
Celery Broker URL
oder so aus den Settings nicht mehr benutzt wird.
Und ja,
ich weiß nicht, wie viele Produktionssysteme das weltweit gebrochen hat.
Es dürften viele gewesen sein.
Ja, ein netter Change, ja.
Ja, und dann habe ich wieder
Downgraded auf 4.4.6 oder sowas und dann war es wieder okay.
Aber so, wow, okay.
Das war schon, hm, naja.
Ich muss mir mal Jungle Q angucken.
Eine Sache,
die eigentlich
total selbstverständlich ist,
die ich aber für mich persönlich erst relativ spät
erkannt habe, ist,
wenn man, also man hat
eine Funktion, also man hat einen Service, man hat
eine höherlevelige Funktion,
die man testen möchte. Und darunter laufen
auch andere Sachen, zum Beispiel, es können jetzt API-Calls
sein, da kam ich jetzt gerade drauf, wegen diesen externen
Sachen mit den Files, aber auch andere Sachen,
die tendenziell auch länger laufen.
Und wenn man den Aufruf der unterliegenden Funktion einfach mockt, dann spart man natürlich einen ganzen Laufen Zeit, weil der halt dann nicht versucht, eine API anzusprechen, weil man irgendwie die API mocken muss oder keine Ahnung was, sondern man sagt einfach, das Ding gibt 27 zurück und gut ist.
Und auf der anderen Seite werden die Tests natürlich auch deutlich besser, weil man isoliert nun den Teil testet, den man eigentlich testen möchte.
Also du musst jetzt einmal noch kurz, einmal musst du ganz kurz erklären, was überhaupt Services sind, vielleicht für alle Menschen, die das noch nicht so benutzt haben.
Okay. Also Django hat von sich aus ja keinen, bringt da keinen Pattern mit, wo man Logik hinpackt. Ja, es gibt Manager für Datenbank-Querys, es gibt Models, es gibt Views, aber wenn man jetzt einfach Logik bauen möchte, die irgendwas tut, also die irgendwie ein CSV generiert, Daten verarbeitet, dafür gibt es halt offiziell nichts, wo man das hinpacken kann.
U-Tilt, Helpers.
Nee, U-Tilt, immer wenn du
ein Modul hast, das U-Tilt heißt.
Das ist schon so ein...
Tatsächlich auf der
Kopenhagener DjangoCon letztes Jahr.
Jetzt muss ich meine ganze Applikation
refactoren, das weißt du.
Ich weiß, ich habe selber solche,
aber eigentlich ist das keine gute Idee.
Weil das Problem ist halt,
naja, was sagt dir das, wenn du
bei irgendjemandem siehst, da liegt halt ein U-Tilt-Modul
rum, was ist da drin?
Ja, das ist wirklich Unsinn.
Ja, weißt du halt nicht.
Aber das ist eigentlich gar nicht so gut, wenn du da zack rumliegst und weißt nicht, was das ist.
Tatsächlich gab es da auch einen Vortrag auf der letzten JungleCon in Kopenhagen,
wo dann auch ein paar Franzosen, glaube ich, drüber geredet haben,
dass sie halt das Konzept vermissen, dass das nicht offiziell in der Doku drinsteht.
Macht das so.
Weil es halt sehr viele Leute so machen, dass man einfach eine Klasse anlegt,
die kann man dann einsortieren, die kann man sinnvoll benennen.
Und dass man da dann halt seinen Code halt irgendwo sinnvoll parken kann.
dann auch, ich meine, das ist halt so eine Art
Best Practice, das ist halt kein offizielles Django-Pattern, aber
ich glaube, das gilt inzwischen als Best Practice.
Korrigiere mich, wenn du es anders siehst,
aber... Nee, ich
weiß, hörst du es nicht, ich weiß
jetzt, das ist aber nicht diese Geschichte, wo
irgendwelche Leute versucht haben, den ORM so
ein bisschen wegzuabstrahieren.
Ich glaube nicht. Genau, auch auf Django News,
die haben auch da Werbung gemacht,
die haben das auch irgendwie Services genannt,
aber ich glaube, das war was anderes. Es ging, das war
dieses Projekt, irgendwie Maintaining a Django Project
over 10.000 Commits oder sowas hieß das.
die hatten so ein paar ketzerische Ideen, die wollten absichtlich
ein bisschen Unruhe stiften, glaube ich, im positiven
Sinne. Ja, ist ja gut.
Muss ich mir, glaube ich, mal angucken.
Kenn ich gar nicht. Ja, also wie gesagt, waren halt
so ein paar ketzerische Ideen, die waren dann auch
und meinten dann so, sie nutzen eigentlich gar keine Packages
mehr, weil wenn das Projekt so lange läuft, hast du
früher oder später immer Scherereien und sowas. Wie gesagt,
die waren da gebrannte
Kinder auf jeden Fall, das hat man gemerkt.
Aber wie gesagt, die haben halt dann
auch, ich habe nachher im Nachgang auch mit denen
gesprochen und die meinten halt auch, dass
die das halt sehr cool fänden, wenn dieses Django-Dinge
in die Django-Doku reinkommen würde, das mit den Services.
Einfach, dass dann halt auch
Newbies, die halt vielleicht nicht so genau wissen, wie es mir
damals auch ging, ich wusste auch nicht, wie ich das mache. Ich habe auch mit
Utils angefangen und hatte dann immer ein ziemliches Chaos
überall rum. Core-App und
Utils. Ja, Core-App ist auch, ja.
Genau.
Ja, das
zu Services. Ja, und du hast gesagt, die kann man
mocken oder die will man mocken oder wann möchte man
das? Genau, also es gibt ja beim
Testing kann man ja alles mögliche
Also man kann die aktuelle Zeit mocken, was ja praktisch ist. Also einfach sagen, heute ist nicht heute, sondern irgendwann anders.
Montag.
Genau. Und man kann aber auch ein Mockblock verwenden. Das heißt, man kann einfach dann sagen, alles, was in diesem Mockblock passiert, wenn da eine bestimmte Funktion aufgerufen wird, füllt ihr die nicht aus, sondern gibt einen festen Wert zurück.
Zum Beispiel, wenn man eine Funktion hat, Load-Data vom API oder sowas, kann man einfach sagen, das gibt ein fixes JSON zurück.
Ein Mock-Block. Schön.
Ja, sagt man, oder?
Und wie gesagt, wenn man das Mocking einmal gesehen hat, ist es eigentlich total offensichtlich, aber ich habe halt irgendwie nie so realisiert oder lange nicht realisiert, dass es halt einerseits total viel Zeit sparen kann und andererseits auch noch deinen Test-Code verbessert.
Weil dadurch, dass halt die unterliegenden Funktionen einen festen Rückgabewert haben, wenn da jetzt ein Fehler drin ist, dann tangiert das halt nicht die anderen Sachen, sondern die Umwandlungsfunktionen, die ja hoffentlich auch getestet sind, fehlen dann isoliert und man hat dann nachher nicht irgendwie 50 gefehlte Tests.
Man muss erstmal anfangen zu suchen, sondern im Optimalfall, wenn alles isoliert genug ist, fällt genau der Test ja nicht mehr, das bringt, was er möchte. Und diesen Doppel-Win, das fand ich echt ziemlich neat, das nochmal so zu realisieren.
Ja, klingt gut. Also ich packe meistens
meine Logik irgendwie so in
den Model-Layer, mehr oder weniger.
Erdmodels, nennt man das.
Genau, oder beziehungsweise dann halt in Mixins,
die dann halt
irgendwie... Die Models aufblähen.
Ja, die ich dann auch oft, wenn es dann zu lang
wird, stecke ich halt in andere Files und importiere die
dann aus Models.py, dann halt da rein und
genau, aber ja,
ja, ich weiß auch noch nicht so genau. Ich muss mir
den Vortrag angucken.
Genau.
Es gibt verschiedene Meinungen dazu, glaube ich, ja.
Ja, definitiv.
Das ist wahrscheinlich auch der Grund,
warum das noch nicht in der Dango-Doku gelandet ist.
Ja, bei TwoScoops sagt er auch,
das ist total katastrophal für Fat Models,
aber ich finde das eigentlich auch gar nicht so schlecht,
weil ich es bei Jochen gesehen habe natürlich,
dass man da viele gute Dinge reinpackt,
die halt da hingehören irgendwie.
So vom Gefühl her machen die halt Sachen mit der Datenbank oder so.
Ja.
Vielleicht sind sie dann am Modeln.
Ich mag das auch.
Also ich würde es nicht sagen,
ich mache jetzt, da ist alles dran,
weil wie gesagt, ich finde das Service-Prinzip ganz nett
und mag das auch ganz gern,
aber die sind auf jeden Fall nicht dünn, die Models, die ich baue.
Ja.
Ja, aber wir hatten noch mal ganz kurz über das Mocken geredet.
Und ich glaube, Mocken ist auch etwas, was noch sehr interessant ist.
Weil man kann natürlich alles mocken und so tun,
als gäbe es irgendeine Umgebung.
Und dann da testen, ob dann das, was man so geschrieben hat,
für diese isolierte Umgebung dann funktioniert.
Ja, und dann funktioniert es in der Realität nicht mehr,
weil der Mock halt anders aussieht als die Realität.
Das ist halt, ja.
Ja, genau. Und vielleicht ist das eines der Probleme.
Also ich habe das schon öfter mal mitbekommen,
dass gerade Menschen, die irgendwie viel Coverage erreichen wollen,
irgendwie sich dann mit vielen moxt und
also es gab sogar Menschen, die haben sich dann Screenshots
von den Webseiten irgendwie
besorgt und dann geguckt, ob die
dann am Ende genauso aussieht, weil sie dann irgendwie Templates
noch versucht haben zu generieren und
dann die Bilder miteinander verglichen
und solche Sachen, also wirklich
abgefahrener Quatsch.
Ja, mockt ihr überhaupt irgendwas
oder findest du anstrengend oder
wann macht man das?
Ich benutze das
sehr häufig und
muss man auch, denke ich, also gerade wenn man
irgendwie APIs fragt oder so, mit externen
sonstigen Systemen redet, dann geht das ja quasi
gar nicht anders. Das heißt, du hast externen Antworten
von Dingen, die du nicht im Test eigentlich abbilden
kannst, die musst du dann tatsächlich emulieren.
Die muss man nicht immer bocken, denke ich, das geht gar nicht anders.
Ja gut, das sind Abfragen von externen APIs,
kann man sich tatsächlich vorstellen, dass das sinnhaft ist.
Ich mache es tatsächlich bei Daten
enorm viel, weil das halt einfach,
also das ist nicht schlimmer, als wenn du irgendwie
am Freitag einen Test ausführst und plötzlich geht er nicht mehr.
Was sind Daten? Also Datums.
Ja, ja, okay, das ist ein bisschen
schwierig im Deutschen.
Aber also wirklich irgendwelche Zeiten, das ist total super. Man kann auch mit diesem, also das heißt Freescan, das Tool, mit dem man das machen kann und da kann man halt auch einen Block machen, also sprich alles, was eingerückt unter diesem With-Tag ist, kriegt dann einen anderen Timestamp, was halt sehr praktisch ist.
man kann das als Decorator verwenden, zum Beispiel sagen,
heute ist der 26.06.
Obwohl das, also egal,
wann der Test läuft. Und wenn man jetzt aber zum Beispiel
sagt, ich möchte jetzt aber Objekte erstellen mit
einem bestimmten Timestamp,
dann
kann ich halt das
in diesem Whiz-Tag machen, obwohl der ganze Test
sagt, ich bin am 26.06.,
kann ich dann trotzdem sagen, dieses Objekt
ist aber schon zwei Jahre alt. Das ist halt ziemlich praktisch.
Wenn man da so zwei, drei Dinge verstanden hat,
dann kann man sich das Leben sehr leicht machen.
Ansonsten das Mocken nutze ich viel weniger, als man es wahrscheinlich sollte. Ich nutze es halt für APIs, also für externe Sachen, die ich halt mocken muss auf Unit- oder Functional-Test-Ebenen.
Und ansonsten, wenn ich halt eine Funktion habe, die halt sehr lange läuft, wo ich halt weiß, ich will die nicht jedes Mal durchjubeln auf allen höheren Ebenen, weil mir das einfach zu lange dauert. Aber wahrscheinlich wäre es sinnvoll, das mehr zu machen. Obwohl natürlich du auch vollkommen recht hast, umso mehr man sich irgendwie da seine Fantasiewelt aufbaut, umso weiter weg bist du doch irgendwann natürlich von der Realität.
Ja, also User-Input oder sowas,
das kann man ja auch ins Frontend weiterdenken, was man
irgendwie alles dann mocken kann. Habt ihr viel Frontend
schon getestet? Was gibt's da alles? Beispielsweise Mocha
und... Nee, nicht wirklich
viel, ja.
So Unit-Tests im Frontend, das ist ja
glaube ich, hat sich inzwischen so Jest als der
Standard etabliert, so ein bisschen.
Reden wir jetzt von JavaScript oder reden wir von
normalen Django-Templaten?
Zum Beispiel JavaScript.
Ich bin bei Frontend da direkt immer schon bei JavaScript.
Ja, ja, eh, aber... Ja, leider, leider.
Ja, das ist ja kurz von der Python-Welt aus,
aber vielleicht ist ein Tester das selbe Thema.
Ja, meintest du denn
Django-Templates-Tests?
Nein, ich meine tatsächlich die JavaScript-Mutter
und was man da alles so bauen kann.
Ja, also ich würde sagen,
da gibt es halt eben den Unterschied zwischen
End-to-End-Tests, also Cypress oder weiß ich nicht,
was Leute da noch verwenden, Selenium.
Da ist wohl die neue Version heute rausgekommen, habe ich gelesen.
Ah ja, habe ich gar nicht mitbekommen, ja.
Cool.
Ja, und ich habe so ein bisschen
was damit gemacht, aber noch nicht so wahnsinnig viel.
Muss man da mehr mocken?
Nö, eigentlich nicht.
Ja gut, ich meine, ja.
Aber ich habe da auch nicht so wahnsinnig viel Erfahrung.
Meistens auf der Django-Seite.
Ja, also entweder braucht man halt gute,
richtig gut funktionierende Apps schon von sich aus,
oder man braucht halt Tests.
Ja, man kann halt auch tatsächlich andersrum anfangen
und kann sagen, man baut zuerst seine
Tests. Das nennt man dann Test-Driven
Development. Und wenn man erst die Tests hat,
die alle verschiebt gehen, dann den Code baut,
was haltet ihr denn davon? Also vielleicht
für mich, ich finde das immer sehr verwirrend,
sowas zu tun, weil
um das zu tun, also erst Tests zu bauen, dann müsste ich
erstmal wissen, was meine Anwendung überhaupt machen soll
oder macht, um dann Tests bauen zu können,
wo die dann diese hypothetische Anwendung irgendwie
stimmen können. Und das alleine ist schon ziemlich
herausfordernd, finde ich.
Ja.
Ehrlich gesagt, ich habe das noch nie so wirklich probiert, weil ich immer dachte, ich muss das vielleicht mal machen, tatsächlich mal versuchen, wie es ist, testdriven zu entwickeln. Aber ja, da ist die Idee ja im Grunde, dass du genau erst immer den Test schreibst und dann erst den Code.
man hört dann halt auf, wenn der Test
funktioniert, aber
also gerade auch bei Django
ich fange meistens, wenn ich
anfange irgendwas zu schreiben
schreibe ich erstmal das in einem Jupyter Notebook
weil
genau, also da gibt es halt
die Django Shell Plus
zum Beispiel, den Django Extensions
wo man halt die ganzen Modelle schon drin hat
sozusagen, das gibt es halt auch
in der Jupyter Frontend
und man hat dann
quasi so eine Umgebung wie in der Shell Plus,
bloß halt mit dem ganzen anderen Jupyter-Kram
drumherum. Genau, man kann halt die ganzen Zellen immer wieder ausführen.
Genau, dann probiere ich halt so lange rum,
bis ich weiß, dass es ungefähr das tut, was ich
gerne hätte.
Das ist super, gerade wenn man so Funktionen machen möchte,
die Modellsachen machen.
Ja, weil oft Sachen muss man halt irgendwie ausprobieren.
Das geht nicht, dann muss man es irgendwie anders machen
und dann, und damit
geht das eigentlich tatsächlich sehr, sehr
schön, während man halt,
wenn man jetzt das tatsächlich direkt in Code schreiben würde,
müsste man das immer irgendwie ausführen.
Man müsste jetzt erstmal an die Stelle kommen, wo das dann ausgeführt wird.
Und das ist halt immer ein bisschen
schwieriger. Und
im Notebook hast du das halt, da änderst du
dann deinen Code, führst nochmal die Zelle aus und weißt dann,
okay, ah, jetzt passt's. Und dann, also
meistens, also da fange ich an,
Sachen zu basteln. Und wenn das dann halt so halbwegs
passt, dann überführe ich
es halt in
tatsächlich Django-App-Code
irgendwo. Und dann fange ich meistens dann auch
Tests zu schreiben. Manchmal
stelle ich dann noch was um, weil es
einfacher ist zu testen oder so, aber
oft ist es dann auch mehr oder weniger schon so fertig.
Das heißt, das Test-Driven ist quasi
gar nicht erst Testschreiben
bei dir, sondern eher so Experimente
machen in so einem Notebook,
die halt so lange durchgehen, bis du halt was
gerade getrunken hast. Also das ist so ein bisschen
Learning by Doing oder man könnte es auch sagen,
ausprobieren
und bis jetzt irgendwas
funktioniert, aber ich sage mal, in Notebooks ist
diese Iterationsschleife relativ kurz.
Relativ kurz, das ist der große Vorteil
Ich kenne es halt aus dem Data-Science-Bereich so.
Und ich weiß nicht, ob das,
ich meine, diese Art, das so zu machen,
gab es halt vorher auch, glaube ich, so noch gar nicht.
Ja, das Pile-and-Error
wird halt einfach dann unheimlich viel schneller.
Und wenn man irgendwann
ungefähr weiß, in welche Richtung man möchte, dann
ja. Ja, also
insofern habe ich das so,
das ist halt das, wie ich das momentan mache, aber
wäre vielleicht auch mal ganz interessant,
Test-Driven-Development mal so wirklich auszuprobieren
oder mal gezeigt zu bekommen von jemandem, der das so wirklich kann.
Aber ja, daher
ist das bei mir eigentlich nie. Das ist das, was
quasi dann im Applikationscode
in der General App landet, eigentlich meistens
schon relativ fertig und die
Tests, die dazu, also meistens weiß ich
dann auch schon, welche Tests ich dann schreiben muss und
dann, ja.
Macht ihr Tests?
Es gibt ein paar Leute bei uns,
die das machen. Ich persönlich
mache es nicht.
Ich bin da ähnlich wie Jochen,
dass ich denke, ich sollte es eigentlich
mir nochmal im Detail angeschaut haben und nochmal vernünftig
zeigen lassen.
Mein Jupyter Notebook ist halt,
dass ich halt meistens mit aktivem Debugger arbeite.
Also sprich, ich springe mit dem
Debugger in den Code, soweit ich bin.
Debugger heißt also, welche Entwicklungs-MG benutzt du?
PyCharm von IntelliJ.
Und ich habe
mir das irgendwann mal
angefangen anzugewöhnen, weil das Schöne ist halt,
du kannst halt dann mit diesem Evaluate Expression
im Debugger, kannst du halt direkt Sachen
testen und ausprobieren. Also sprich, wenn du dir nicht
ganz sicher bist, zum Beispiel, ob eine Query das zurückgibt
oder wenn man jetzt irgendein komplizierteres
Aggregate macht, geht das, funktioniert das wirklich
und solange man nicht versehentlich auf
Steuerung S, also Speichern drückt und der die Seite
neu lädt und dann der Debugger neu startet,
hat man halt
den Debugger, auch wenn man da ganz viele Änderungen macht
und kann sich dann natürlich irgendwelche Zwischen-State
in eine neue Variable speichern und weitermachen
und...
Das ist ein sehr interessanter Ansatz, würde ich gerne tatsächlich mal live sehen,
also weil so, ich glaube so ein bisschen
macht der Jochen das und ich mache das auch,
ein bisschen abgucken mit den Notebooks, weil du da halt auch immer diese
Iterationen dabei hast und auch, also
ich benutze VS Code manchmal,
da kann man das ja auch machen
mit dem Debugger, den ich aber selten für sowas benutze,
also nur wirklich, wenn ich ein Problem habe, was ich so nicht so einfach
verstehe, dann gucke ich da mal rein
und Python macht das. Also für mich
persönlich, also mir geht es ein bisschen so,
wie das verstand ab euch beiden auch,
ich weiß halt am Anfang meistens
nicht so genau, was nachher rauskommt, also
wenn die meisten Sachen, die man
ja so zu testen hat, sind ja dann bei mir jetzt in Services
und ich weiß halt einfach
nicht, wie der Service nachher aussieht.
Hat der nur eine Process-Methode, hat der mehrere Methoden, wie sehen meine internen Methoden aus?
Ich habe dann noch nicht so ein Bild davon, das entsteht erst während ich daran arbeite und ich dann merke, ah, ich habe vielleicht noch was vergessen und das wächst dann irgendwie.
Das heißt, ich fange dann eher an, baue einen Service, also eine Klasse, packe da einen Process rein und überlege dann, okay, dann schreibe ich ein bisschen Code mit dem Debugger an, merke, okay, das müsste ich kapseln, das ist nicht testbar sonst, weil da sind zu viele Sachen drin, ziehe das raus, dann baue ich da wieder Sachen dazu und so wächst das dann halt mehr oder weniger von innen nach außen.
Und ich müsste halt sehr meine Denke umstellen, wenn ich halt erst mir überlege, was möchte ich denn eigentlich so genau alles testen, also was kommt nachher alles raus, weil teilweise manchmal habe ich auch, wenn ich anfange, eine ganz andere Idee von dem, was nachher rauskommt, was ich nachher habe, weil ich nachher eine gute Idee habe und merke, das könnte man vielleicht alles besser, schneller, effizienter, komplett anders machen und ja.
Also ich denke, TDD ist auf jeden Fall ein sehr hehres Ziel, das zu machen und ich glaube auch, dass Leute, die, sag ich mal, programmieren lernen, das auch bestimmt nicht verkehrt ist, wenn die so anfangen.
Nee, ich glaube, das ist für sich ganz anders, weil die Leute wissen gar nicht, was sie bauen können.
Und wenn die nicht lernen, dann, wenn die Tests schreiben, die sind sowas von überfordert.
Okay, ich formuliere um. Für Leute, die schon programmieren können, aber jetzt, sag ich mal, so ein bisschen mehr in die, also die so, sag ich mal so, das Grundhandwerk verstehen und jetzt anfangen, dann wirklich produktiv arbeiten zu wollen.
Weil zum Beispiel bei mir, als ich angefangen habe zu programmieren
und auch Python gelernt habe,
da war mein Code, den ich geschrieben habe,
also ich habe damals eh noch keine Unit-Tests geschrieben,
ich meine, das ist auch schon lange her,
aber der Code, den ich produziert habe,
der war nicht gut strukturiert, der war nicht gut testbar.
Und wenn du halt TDD machst, dann wirst du halt von Anfang an gezwungen,
dass dein Code die richtige Struktur hat,
weil du merkst halt sofort, oh, der ist ein Code, den kann ich nicht testen.
Aber du hast jetzt gerade einen Bias, du hast gesagt, die richtige Struktur.
Du hast gesagt, dass die Struktur, die man gut testen kann,
die richtige wäre.
Eine bessere.
Aber ich glaube auf jeden Fall, dass Code, der nicht testbar ist,
nicht so richtig guter Code ist.
Das würde ich jetzt einfach mal so posten.
Und das zum Beispiel hat mir,
als ich dann angefangen habe, mich intensiv mit Unit-Tests zu beschäftigen,
halt sehr geholfen, auch nochmal
wirklich beim Codeschreiben auch zu überlegen,
wo soll das denn alles hin?
Wenn ich halt weiß, ich möchte das irgendwie isoliert
und vernünftig, also ich möchte nicht irgendwie nachher drei Stunden
über Tests nachdenken und irgendwelche wilden Fälle zusammenbauen,
sondern ich möchte es ja einfach, es funktioniert, ich mache ein oder
zwei Sachen, genau das möchte ich abchecken, ob das nachher rauskommt
und fertig. Und wenn man halt
das nur baut, dass es funktioniert und
gar nicht über diese Tests nachdenkt,
ja,
das ist halt, glaube ich, ein Unterschied. Von daher glaube ich,
kann das, also ich glaube, für Leute, die schon
relativ gut wissen, was sie tun, kann das
natürlich eine Verbesserung sein.
Wir hatten mal vor vielen,
vor zwei Jahren einen,
ich sag mal einen Python-Guru bei uns in der Firma, der mal
so einen Tag lang über TDD
erzählt hat und im Endeffekt querbeet alles
Mögliche und
war das auch mein erster
intensiverer Kontakt mit TDD
und ich habe ihn im Nachgang auch gefragt,
hey, guck mal, ich arbeite so und so, was sagst du dazu?
Ich meine, du hast die hier.
Und er meinte dann, er meinte im Endeffekt
ist es halt so, es gibt halt
viele Wege, die nach oben führen. Er selbst findet das gut,
er macht das auch so, er hat auch irgendwann mal umgelernt,
aber für ihn zum Beispiel
ist halt wichtig, dass testbarer Code rauskommt.
Und wenn man halt selbst durch die Art,
wie auch immer man da hinkommt,
wenn ein Testparachoder am Ende rauskommt,
dann ist halt ein großer Vorteil von TDD,
hat man halt anders erreicht.
So what?
Eine Sache, die ich auch ganz interessant fand,
ist, bei TDD fängst du an und schreibst einen Test,
der per se failen muss,
weil es gibt ja noch nichts, was funktionieren kann,
weil du ja mit dem Test anfängst.
Und das fand ich ganz spannend.
Er meinte, er findet das,
das ist für ihn so die Routine,
er fängt irgendwas an zu programmieren
und sieht erst mal, der Test schlägt fehl.
Und wenn man andersrum arbeitet,
dann baut man die Tests ja so, dass sie funktionieren.
Also du baust ja nicht absichtlich einen Test und baust einen Fehler ein,
um den Test rot zu haben.
Und er meinte, das ist halt ganz angenehm, dass du am Anfang siehst,
okay, ich habe jetzt acht Tests gebaut, die schlagen alle acht fehl
und nachher mache ich, dass sie gehen.
Weil es kann halt leicht passieren, dass wenn man halt das andersrum macht,
dass man halt die Tests baut und dann hat man einen Fehler drin,
und der Test ist versehentlich grün, also voll positiv.
Und tatsächlich ist mir das auch mal passiert in einem Projekt,
da hatte ich ein Rechnungsmodul gebaut,
also auch zahlungsrelevant und ziemlich heikel.
Und irgendwie ist dann irgendwann mal, das sah auch alles immer super aus und grün und so weiter.
Und dann irgendwann ist halt mal die InitPy weggekommen aus dem Testordner, wie auch immer.
Und naja, dann sind die halt plötzlich mal ausgeführt.
Der Projektor der damals, glaube ich, 800 Tests, die 50 Tests für die Rechnungslegung,
ist dann halt nicht aufgefallen, dass die nicht mehr drin sind.
Ja, und irgendwann waren dann da halt Fehler in der Rechnung und ich dann so,
hm, irgendwie kann das nicht sein, ich habe das doch getestet.
Und dann war das so, ups.
Ich meine, das trifft jetzt nicht so 100% deckungsgleich mit dem, was ich jetzt gerade meinte.
Aber solche Sachen, es gibt halt schon echt Beispiele, wo man das haben kann. Ich finde diese Idee echt ganz nett, dass man wirklich mal guckt, so hey, funktioniert das denn wirklich? Weil es kann ja wirklich sein, dass man testet einfach, dass der versehentlich funktioniert. Zu viel gemockt oder so, man weiß es nicht und ja.
Ja, nee, absolut.
Spannendes Thema. Ich würde jetzt gerne noch ein paar Getränke hier testen. Was haben wir denn noch auf unserer Liste? Ich glaube, die Liste sind wir ganz gut, oder?
durch? Wir sind durch?
Nein. Wir sind voll vorbereitet, wir haben eine Liste.
Die hast du selber geschrieben, ich kann gar nichts lesen.
Du kannst ja schon mal die Liste lesen. Ich kann ja vielleicht noch mal
gerade, also ich bin immer noch ganz begeistert
von dem Sweet Up Your Django Tests
Buch und
genau, was man nämlich auch noch alles machen kann,
an tollen Sachen ist, man kann halt auch noch die Datenbank
auf ein
In-Memory-Filesystem legen. Es gibt
zum Beispiel mit Docker, Docker Compose geht das sehr einfach.
Das ist eine gute Idee. Ja, und das macht
die auch nochmal gleich deutlich schneller, weil
normalerweise kannst du das halt nur machen mit SQLite
und SQLite will man vielleicht nicht verwenden, weil
es ist halt anders als Postgres oder was auch immer.
Ich wollte gerade sagen, kann man damit denn so Postgres
Testen, wenn ich jetzt zum Beispiel
in Postgres habe ich jetzt sowas wie Indexes bauen
oder sowas? Ja, ja, ja, das funktioniert alles.
Das ist halt das drunterliegende Fallsystem,
was dann halt nur noch im Hauptspeicher ist.
Ich muss ja
gestehen, ich hatte ja, wir hatten ja
erst geplant, das bei dir daheim zu machen und ich hatte
gehofft, dass da zu viel das Buch herumliegt, nicht
in meinen Blick reinwerfen kann. Achso, nee, ich hab's nur elektronisch,
ich hab's nicht, genau, aber
Aber ja, lässt sich sicher sonst auch machen.
Irgendwie muss man gucken.
Ja, nee, stimmt.
Ja, ich bin inzwischen fast komplett umgestiegen
auf elektronische Bücher, weil ja, praktischer Platz.
Und ich habe sie immer dabei.
Der einzige Grund ist, du hast keinen Platz mehr im Regal.
Ja.
Alles voll, fällt schon alles raus.
Doppelt, dreifach, kennst du das auch?
Mehrere Stapel an Bücherlagen im Regal.
Ja, ja, bei den meisten Bücherregalen
ist bei uns mindestens eine Lage noch dahinter.
Ja, genau. Lass mal überlegen, was war denn da? Gab es sonst noch irgendwie interessante Dinge, die im Buch drin standen? Ja, es gibt dann auch irgendwie auch so grundsätzliche Dinge. Genau, Tests parallelisieren bringt sehr viel. Migrationen bringen auch viel, wenn man die squasht.
Oh ja.
Das ist halt auch sowas, das sollte man vielleicht ab und zu mal machen.
Vor allem auch, wenn man so lustige
Sachen hat wie RunPython, also dass man wirklich
noch Code ausführt, das kann
ja, je nachdem,
ich meine, man hat ja meist eine Testdatenbank, wo nicht so
viele Datensätze drin sind, aber das je nachdem,
was man da für abgefahrene Dinge tut, kann das auch schon
ein Downer sein.
Ja.
Ja, aber ansonsten glaube ich,
ja, nee, muss man selber mal
gucken. Ich meine, wenn man sich das Blog
von Adam Johnson anguckt, da sind auch die meisten,
also ich meine, das Buch ist, viele von den
Sachen, die darin stehen, hat er auch schon mal irgendwie als
Blogartikel irgendwie da an seinem Blog gehabt.
Der hat einfach gewagt, an seinem Blogartikel schon ein Buch
zu verwurzeln. Wahnsinn.
Könnte man von lernen.
Ja, genau.
Ansonsten,
ich weiß es nicht, gibt es noch irgendwelche Dinge,
wir haben jetzt viel über Django geredet, gibt es irgendwie
Testgeschichten, die auch
relevant wären, die jetzt nicht so sehr
Django oder Webentwicklung betreffen?
Lass mal überlegen, habe ich irgendwas mit
Data Science? Also da
ist es auch so, da macht man auch viel Tests.
Aber das ist auch alles sehr ähnlich.
Fast alles Unit-Tests,
die einzelnen Test-Cases.
Eine Sache, die ich noch ganz interessant
finde,
das geht wieder so ein bisschen Richtung
100% Test-Coverage.
Ich habe mich auch mal mit jemandem unterhalten und
da meinte er, er ist gar nicht so ein Fan
von Unit-Tests. Ich finde, natürlich braucht man die.
Die gehören einfach zum Team.
Er meinte, da hat er es so ein bisschen mit den drei Musketieren verglichen.
Also Arthos, der ist so ein bisschen langweilig, aber der ist halt der Chef.
Die brauchst du halt einfach, kannst nicht ohne.
Und was er halt viel cooler findet, sind halt eher Functional Tests.
Also sprich Tests, die halt die Business-Logik testen.
Also dass man halt so ein bisschen mehr High-Level-Sachen testet,
um einfach sicherzustellen, dass, keine Ahnung, wenn man halt irgendeine Logik hat,
die irgendwas macht, also eine Rechnung erstellen oder irgendwas berechnen
oder irgendeine Daten aggregieren oder sowas,
dass die halt das tut, was man von ihr möchte.
Und das fand ich ganz lustig, weil meistens, wenn halt über das Testing gesprochen wird, dann werden halt Unit-Tests rauf und runter exerziert. Und dann wird auch immer wieder gesagt, so ja, dann gibt es natürlich die End-to-End-Tests, wo man natürlich das Frontend drin hat, wo man dann wieder in einer ganz Django-fernen Welt, oder was heißt Django-fern, das ist halt dann, tangiert Django nicht direkt, sage ich mal.
Das wird natürlich dann irgendwie aufgerufen und genutzt, aber das ist dann ja auch bei Cypress dann JavaScript-Code und sowas. Und dass man diese Functional-Tests, die kann man halt auch problemlos im, also selbst wenn man Django Headless verwendet, also ohne das Django Forms, Views, Templates etc., kann man diese Functional-Tests halt problemlos bauen.
Das ist natürlich meistens ein bisschen mehr Setup, weil man halt nicht ein bisschen mehr Cases zusammenbauen muss, aber ich mache das eigentlich für alles, was ein bisschen aufwendiger oder größer und netter ist, mache ich das eigentlich immer, dass ich noch zwei, drei so Functional Tests hinterher schiebe und wirklich einfach sage, ich baue mir so ein Case auf und gucke einfach so, hey, angenommen, ich habe jemand, der, keine Ahnung, ich habe eine Rechnung, enthält die dies und jenes, dass man wirklich, klar, die Teile sind natürlich, die Unitests sind natürlich da, das braucht man natürlich, weil sonst findest du ja nie einen Fehler oder kannst nicht sicher sein, wenn du was kaputt gemacht hast.
Aber diese High-Level-Tests, oder Higher-Level-Tests, sage ich mal, die sind ja nicht richtig high, das finde ich schon ganz nett.
Und das wird, finde ich, manchmal so ein bisschen übersehen, dass das halt auch geht und dass das auch einen sehr großen Mehrwert bringen kann.
Naja, durchaus. Ich weiß gar nicht, ob es da irgendwie so tolle Definitionen von was ist ein Unit-Test, was ist ein Functional-Test, was ist ein Integration-Test, keine Ahnung, aber weiß ich auch nicht.
Du hast gerade von den drei Musketieren gesprochen und erst ein einziges Musketier erwähnt.
Genau, also die Functional Test ist Porthos, der Coole, der Pirat und die Integration Test ist dann Aramis, glaube ich, heißt der letzte.
Die anderen beiden waren? Ja, stimmt, du hast es ja schon.
Also Arthos, Porthos, Aramis und dann D'Artagnan gehört ja nicht so richtig dazu.
Nicht, dass der, der das Beispiel gebracht hat, mich jetzt hautweiß durcheinander bringe, aber Arthos ist auf jeden Fall der langweilige Unit Test.
dann Porthos, glaube ich, war
das coole. Vielleicht waren das auch
die End-to-End-Tests, das weiß ich nicht mehr genau.
Also da sind ja auch noch Porthos, weil die sind beide so
und genau
Aramis ist dann Integration-Test, wo man
so externe APIs und sowas mit anspricht und so
und das ist dann halt immer so ein bisschen
das ist zwar total cool
und jeder mag den Charakter auch, aber der ist halt so ein bisschen
schwierig. Der ist dann irgendwie ständig verliebt und irgendwie
Seelenkrise und so und das ist dann auch so mit den externen APIs.
Es ist total cool, das zu haben, aber man hat halt auch
irgendwie ziemlich viel Scherrein damit
und ja.
Der Wind kommt, der wird die Tests gerade machen.
Ich glaube, das war
Porthos,
ist die End-to-End-Test, weil die halt
ziemlich cool sind, weil du halt damit wirklich den kompletten Flow
durchtesten kannst. Und diese Functional-Tests sind
d'Artagnan, der gehört zum Team
und der wird aber oft übersehen.
Weil das heißt immer nur die drei Musketiere und nicht die vier.
Ja.
Ja, ja.
Königin der Kunde oder sowas.
Die entscheidet dann tatsächlich, wie es mit dem
weiterläuft. Mit den dreieinhalb,
vier.
Ja, fällt euch noch was
ein zu testen?
Ich teste glaube ich
noch Weltenwein. Ja, genau.
Ich meine, ich glaube, wir sind eigentlich
so halbwegs durchgekommen und so.
Die erste Folge draußen war gar nicht so verkehrt.
Also ich hoffe, es ist nicht
zu schrecklich. Ich bin mal gespannt, was
auch Vanek draus macht.
Ja, genau. Ja, alles klar.
Ja, vielen Dank auf jeden Fall für die Einladung.
Also fand ich cool. Ja, schön, dass du da warst.
Mein erster Podcast
und ja, war echt cool, hat Spaß gemacht.
Ja, schön, dass ihr da reingeschaltet habt.
Vielen Dank, dass ihr da wart.
Schreibt uns auf hallo.peisenpodcast.de und bleibt uns gewogen.
Bis zum nächsten Mal.
Tschüss.
Tschüss, ciao.