Transcript: Tests

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