Transkript: Tests

Ja, hallo und herzlich willkommen zum Python-Podcast in der 24.

Episode.

Heute geht es mal 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 auch da.

Ja, schön, dass ihr alle wieder eingeschaltet habt.

Und Ronny, erzähl doch mal.

Möchte ich euch einmal kurz vorstellen?

Ja, ich heiße Ronny Vedriglia, ich arbeite in Köln bei Amin Innovation.

Bin da jetzt seit einem Jahr ganz offiziell Tech-Evangelist für Django.

Hab jetzt meine acht Jahre, die ich da bin, als auch großteils mit Backend-Arbeiten und Django verbracht.

Hab in Köln Wirtschaftsinformatik studiert, also eigentlich eher so einen Beraterstudiengang, aber ich hatte immer mehr Spaß eigentlich am entwickelnden Beraten, beziehungsweise Beratung mit Entwicklung zusammen.

Kann ich ja gar nicht erstehen.

Und genau.

Hab dann, wie haben wir uns eigentlich kennengelernt?

Du warst PayColog oder Düsseldorfer?

Ja, und du hast dann dieses Meetup ausgerichtet, das Django Meetup in Köln.

Hatten wir uns nicht vorher schon?

Wir haben uns auf irgendeinem der Paikolons mal gesehen.

Paikologon bestimmt, da haben wir es bestimmt schon mal gesehen.

Genau, und wie Dominik gerade schon gesagt hat, seit glaube ich im 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 das Live kennenlernen wollt.

Bis Corona all das verunmöglicht hatte, sozusagen.

Also, na gut, es gibt halt das virtuelle Meetup und ja, genau, das ist natürlich.

Ich fand es auch mal schön, die Leute live zu sehen.

Apropos Live-Sen, 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 entschuldigt, so ein bisschen die Hintergrundgeräusche, so ein bisschen urbanes Leben.

Ja, schreibt da gerne mal Feedback zu, ob ihr es wollt.

Klingt das ganz schrecklich furchtbar oder kann man mit 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, das ist natürlich schon sehr viel angenehmer als jetzt.

Dankeschön.

Naja, hört sich sofahren.

Der sind zu voll.

Ja, aber eben wenn man in so einem kleinen Raum setzt.

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 HALT, 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 ihn auch.

Ja, auf jeden Fall, genau.

Also wenn ein 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 Mobilis-Equipment, dass wir neben 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 kommt.

Ja, aber du kannst gerne nochmal ein bisschen über die Gerätschaften erzählen.

Du machst ja schon ein letztes Mal irgendwie.

Naja, das ist jetzt einfach so ein Zoom H6, das ist halt so ein Field-Recorder, das hast du das beworben.

Es hat halt auch so XLR-Eingänge für Mikrofone, macht Phantomspeisungen und dann halt 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 dranhä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 zurzeit, glaube ich, so, die am meisten Audioqualität bietet für Geld, ist halt so ein Zoom H6 plus irgendwie diese HMC660X oder C, keine Ahnung, Headsets, weil man kann an dem Zoom H6 nämlich auch 12 Volt Phantomspeisung einstellen.

Ja, muss das nicht werden.

Man braucht keine, 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 der Hintergrundakustik.

Also man hört ja manchmal den Windrauschen, das Lachen der Gäste, die leise Musik.

Ronny, Tests heute.

Ja.

Oder wollen wir zuerst irgendwie, gibt es irgendwelche News und die

Pass überlegt?

Ja, so Dango 3.1 kam ja raus, ich weiß nicht, jetzt ist tatsächlich final.

Und Wagtail wurde auch schon auf Dangrote 1 gearbeitet.

Das habe ich auch noch mitbekommen.

Ja, es gibt eine neue Wagtail-Version, wobei die da war nicht so weltbewegendes dabei.

Doch, es geht jetzt mit Dangota 1.

Achso, ja, okay, gut.

Ich habe da recht tatsächlich umgestellt.

Du hast einen tollen Artikel geschrieben, irgendwie auch.

Ja, das war, ich meine, das ist halt irgendwie so mehrere Probleme mit einer Klappe fliegen erledigen, halt sozusagen, weil ich die Geld verstanden habe.

Ja, wir schreiben auch noch gerade

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 Assung-Folge gemacht, die halt.

Hast du Django News, Ronnie?

Ja.

Ja, der war ja, weil der erste Artikel war von ihm.

Ich hab's auch gesehen.

Ich war 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, die kriegt gerade über sein Brenglas.

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.

Es gab 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 gedacht, ich habe keinen Bock mehr, weil das ist so machen, jetzt reicht's.

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.

Ich wollte gerade sagen, das ist ein bisschen so.

Also ich habe ja irgendjemand so angefangen damit erstmal, ne?

Jochen, der so um die Ohren gehauen, ist unglaublich.

Er meinte ja so, nee, das geht gar nicht.

Und hat dann irgendwie 15 oder 16 Seiten dran gehängt, wie man es richtig macht.

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.

Ah ja.

Den ersten.

Gibt es jetzt.

Also, und Leute, die das verwenden, haben schon gesagt, ach, es funktioniert eigentlich alles ganz fluffig.

Was ist denn den neueren von 3.9 haben wir die nicht?

Ich hab's.

Und ich kann es jetzt auch nicht nachbauen.

Die haben jetzt ja kein Rechner in der Nähe.

Wir können es nicht an.

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 es auch schon nutze, funktioniert gut.

Jason fängt

zum Zoom, wir hält noch was ein und zwar ist von Daniel Royal Feetroy das Buch Two Scoops of Django in der Version 3, hat er gestern Abend seinen Twitch-Kanalbuch gefahren, weil es jetzt offiziell release worden 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ß, dass es Release ist, super, dann hole ich mir mal die Komponenten.

Ganz genau, das war gestern Abend.

Ah, sehr schön.

Ja, nö, ansonsten, genau, können wir dann vielleicht direkt mit dem echten Thema einstellen.

Ja, wollen wir vielleicht einen kurzen Ü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, mehr Tests, also der Test funktioniert mit den Tests.

Mögt ihr Tests?

Jochen.

Ja, also ich habe lange Zeit, ich hab wie früher die Leute, die so anfingen mit TDD oder so.

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 mal gelächelt und dachte ich so, ah ja, die mit ihrem komischen statischen Dingstarjava und so und Testschreibenhöhe.

Das mache ich alles einfach mal so eben außerhalb.

Und mein Kohle

so perfekt, den braucht man gar nichts mehr.

Man kann keine Fehler machen, so einfach ist

das, ne?

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 gern 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 längere Programme schreiben.

Mit Tests geht das plötzlich.

Das ist halt, wenn man, wenn man, 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, Sonny?

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.

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 einer 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 Unitests 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 jetzt mitbekommen, ich bin jetzt noch nicht so lange dabei, dass es eine große philosophische Debatte gibt zwischen Menschen, die gerade haben mich viel Testabdeckung, 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 Integrationstest, ob überhaupt so die Permissions so sind, wie ich mich das vorstelle.

Und dann, wenn halt was schwierig schlägt, dann schreibt man danach dafür einen Test, dass es nicht nochmal passiert.

Irgendwie so dazwischen ist so der Wahrheit.

Ich weiß nicht, ob es sowas gibt wie so manches Mal.

Aber ich glaube auch, also ich meine, es gibt ja dieses 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 auch einfach mal in die Hose gehen dürfen.

Also vor allem,

es wird doch so starr, ne?

Also wenn du halt ganz, ganz, ganz viel testest, dann kannst du eigentlich ja nichts mehr ändern, ohne dass irgendein Test viel schlägt.

Ich meine, du merkst ganz zwar, was dann viel geschlagen 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 dann gefactort werden müssen dann.

Ja, also ich würde auch denken, es kommt halt auf den Anwendungsfall an, als wenn du halt irgendwie eine kleine Webseite hast, die irgendwas, keine Ahnung, für dich und ein paar Freunde irgendwie macht, dann braucht man vielleicht keine Tests, weil wenn irgendwas schief geht, dann fix man das halt und es hat ja keinen gestört, dass es irgendwie schiefgegangen 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 schieflä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, ja, es ist 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 beim Code.

Weil man dicke Integrationstests, die ganz viel Code aufrufen und 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, 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 der Test, ob irgendein Test getestet hat, ob beide Pfade genommen werden und so.

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 Cavali das auch, dass man sagt, man kann auch zu jedem Pfeil 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 Test-Models PY.

Und die Abdeckung, die daher kommt, 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.

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 Kabierendes kaputt gemacht.

Ja.

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 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 Businesslösungen, also wie man irgendein speziellen Business Case halt digitalisieren kann.

Das ist auch wegen dem Wirtschaftsinformatik-Hintergrund, wird das halt ein ganz, ganz gutes Match.

Und haben halt dann früher am Ende gesagt, okay, Tests schreiben, dauert Zeit.

Ja, 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 es ist ja quasi ein Mehrwert für den Kunden, weil die Software dann besser funktioniert und haben dann halt sehr idealistisch 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üsstest du 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 irgendwie auf die Nase fällt und du kannst ihm das vorher erzählt und er bezahlt es halt nicht.

Dann fällt es halt auf die Nase, ja.

Also man steht halt ein bisschen blöd da, ne?

Das ist schon richtig.

Aber also viele, die ich so mitbekommen habe, an kleineren Kunden vor allen Dingen, die dann sagt, naja, jetzt können wir es nicht leisten, Test machen wir jetzt nicht.

Die kamen dann irgendwann rollmütig zurück, ja, wir haben jetzt so eine Software gebaut und es wurde kein Test geschrieben, es funktioniert alles nicht mehr.

Wir haben irgendwas, vielleicht haben die selber irgendwas angepasst, ja, da konnte irgendjemand von den Menschen aus der Firma so ein bisschen Django und hat dann irgendwas umgebaut und irgendwas kaputt gemacht oder irgendwas anderes, was ihm erst später aufgefallen ist.

Ei, ei, ei.

Ich muss sagen, also dafür, dass wir erst, also dass wir die ersten Jahre, als wir noch ganz klein waren, tatsächlich keine Tests geschrieben haben, haben die Sachen trotzdem überraschend gut funktioniert.

Also es wundert mich rückblickend auch.

Ihr seid also 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.

Ihr habt ja 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're all adults hier, 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 haben bei uns nie das Problem, was man halt sonst, zum Beispiel meinen Studentenjobs oder 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 Mehrwert sehen.

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 in internen mittlerweile als Security-relevant.

Also wenn es keine Tests gibt, dann ist er ganz viel Sicherheiten da, muss er sicherstellen, dass das nicht mehr so ist.

Also, ja, ich bin mir nicht sicher, ob es da nicht inzwischen, also wirklich, ich glaube, wir hatten das Thema auch schon mal in der Projektmanagement-Episode, aber ob es 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 gern lieber mehr Geschwindigkeit.

Die Musik hat sich übrigens gerade eben geändert, ich hoffe, ihr hört das nicht an.

Es war eben so schön entspannt und jetzt haben sie ein bisschen mehr Beats reingebracht.

Ja, ich treffe das ja so ein bisschen durch die Nacken.

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 gern 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 auf der Entwicklerseite, weil dann kein Entwickler dürfte sich darauf einlassen, weil das ist nicht.

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

Weil ich irgendwie damit sozusagen auch mich selbst sabotiere.

Ich meine, man wird dann ja auch schlechter, wenn man irgendwie, man lernt das dann ja, dass man halt rumschlammt und so.

Und das ist eigentlich alles, das will man einfach alles gar nicht, sondern man möchte eigentlich mit weniger Zeit mehr hinbekommen.

Man lernt rumzuschlampen, das finde ich auch nicht so schön.

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 ein Marketing-One-Pager gemacht, keine Ahnung, also so 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 das braucht kein Mensch mehr.

Ja, gut, klar.

Das sollte natürlich trotzdem funktionieren.

Das merkt man ja beim Angucken schon fast, ne?

Also wenn man einfach Lugalhust aufmacht.

Aber wenn man halt sagt, so, hey, das ist irgendwie jetzt vielleicht was, was Firmen strategisch relevant ist, da kommetet 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 Test angefangen haben, ziehen wir die jetzt auch einfach nach.

Weil ich meine, das ist halt einfach sinnvoll.

Und man kann inzwischen.

Man macht das dann auf eigene Kosten oder sagt dann der Kunde, ja, okay, das ist jetzt hier in unserem Supportaufwand.

Wir machen das eigentlich so, dass wir jetzt halt sagen, die Tests sind ein elementarer Teil der Programmierung.

Also das ist halt so, als ob man sagt.

10 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, cover it 100%, weil wie gesagt, ich glaube einfach 80-20-Regel, ich glaube in 80% der Zeit, also 80% des Notwendigen kriegt man 20% der Zeit hin.

Und keine Ahnung, wenn ich irgendwelche Django-Views oder sowas habe, die mehr oder weniger einfach getestete Django-Funktionalität ausführen, ich schreibe ich keinen Test dafür.

Wenn ich irgendwelche Permissions drin habe, an denen ich selber rumgebastelt habe, okay, das ist was anderes, ja, weil das kann echt mal schnell in die Hose gehen.

Aber so Standardfunktionalitä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.

Also was uns übrigens interessant für unsere Hörer, wir reden gerade die ganze Zeit noch von Django, ja.

Also Testing kann man ja auch außerhalb von Django Test.

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 Unitests-Modul aus der Stande-Bibliothek oder halt eben PyTest, wobei ich sagen würde, wenn ich mich so umgucke bei den Projekten, in denen ich irgendwie beteiligt bin, ist die Mehrheit inzwischen auf Py-Test.

Und Unitest fühlt sich so ein bisschen an, als das sind immer so die etwas älteren Sachen und die etwas nicht so ganz gut abgepflegten.

Und ich meine, natürlich hat das irgendeinen gewissen Charme, dass es für eine.

Erklär mir nochmal kurz, was denn überhaupt der Unterschied zwischen Unitest ist und was Pytest an Neu rumbringt.

Und es gibt noch einen Nose-Test oder sowas.

Ja, Nose war früher ein Testfraner.

Ich glaube, das ist inzwischen gar nicht mehr wirklich maintained.

Ich habe gehört, Johannes benutzt noch viel Nose.

Ernsthaft?

Okay.

Vielleicht bist du ja auch Unitest, ich weiß es.

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 Unitest ist irgendwie eine Portierung von J-Unit 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 Jaden Unit und warum ist das so anders als das?

Ja, zum Beispiel einfach allein, dass die Methoden namen Camel Case sind, ist halt 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 was?

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 wie das man da.

Ja, also wenn man jetzt zu, wie schreibt man Tests, kommt, also da ist es halt, nennt man so AAA, wie heißt das, Range,

wenn man es baut?

Oder sowas und es hört 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 halt hinterher, ist jetzt alles in sozusagen gefälligerweise wieder drüber zerfallen und es ist so passiert, wie es hätte, wie es ist ja sozusagen Schornstein in die richtige Richtung, der Baum in die richtige Richtung umgefallen sozusagen nach dem Jahr.

Und das macht man halt bei Unitest in der Klasse.

Die Task-Test-Case, ich glaube, Django Test-Case ist auch, erbt auch von einem Unit-Test-Case, oder?

Ja.

Also es gibt bei Django vier Test Case-Klassen, aber ich glaube, die erben alle von Test Case, ja.

Genau, bei PyTests ist es so, da können auch Tests einfach Funktionen sein.

Und es ist halt nicht Camel-Case, sondern Snake-Case oder keine Ahnung, mit Anderscores halt.

Und man verwendet halt nicht Methoden auf dem Test, um zu assorten, sondern man benutzt einfach das Assert-Statement.

Das macht PyTest ja jetzt auch dann.

Das macht PyTest.

Unitest macht das nicht.

Okay, also bei Unitest gehst mal diese Asset Equals, das hat mich immer so ein bisschen gewundert.

Genau, genau.

Super, super Beispiel, genau.

Wisst ihr das, was die richtige Methode ist, Assert Equals oder Assert Equal?

Ich glaube ohne S, oder?

Ja, siehst du, weiß ich jetzt auch gar nicht.

Eins von beiden ist richtig, das andere ist nicht gut.

Python zeigt mir mal an, dass, glaube ich, das mit S, das ist immer durchgestrichen wegen Deprecation.

Ja.

Assert Equal.

So, eins von beiden ist deprecated, genau.

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

Also 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, die sind die Funktionsaufrufe zu geben.

Da passieren irgendwelche magischen Dinge im Hintergrund, wo ich gar nicht weiß, ob das so stimmt.

Ja gut, wenn eben, wenn du sozusagen bestimmte Sachen mit einem gefälten Test machen willst oder so, dann kannst du das ja quasi nicht gar nicht so richtig gut anders machen, oder?

Ich weiß nicht genau.

Ich weiß es nicht.

Vielleicht ist auch einfach nur Geschmacksgeschichte.

Wie ist das denn mit zum Beispiel mit den anderen Assert, zum Beispiel Assert Races?

Kannst du das auch über Assert-Statement abbilden bei PyTest?

Ja, aber es kann sein, dass man jetzt Test.

Nein, nein.

Aber das kann sein, also das ist auch ein Kontextmanager, es ist irgendwie with irgendwas, Races, aber ich glaube, man importiert da irgendwas aus PyTest.

Also Hintergrund ist ja einfach nur, dass 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 einen Kollegen, der sehr auf PyTest schwört 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 Py-Test irgendwie gelernt, in Afonso.

Modus hast du immer viel und da gibt es halt diese Fixtures.

Gibt es die auch so bei Müll-Tests ohne Py-Tests?

Also ich dachte, das wäre so ein PyTest-Exfeature.

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 JSONs und ich muss halt dann dadurch meine Sachen bösen.

Aber das ist jetzt nur Django, das ist nicht Unit-Test.

Also ich weiß nicht, wie nur ein Test das machen würde.

Also ich kenne das jetzt als Pi-Test, dass ich tatsächlich meine Fixture-Funktion 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 auch 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 Fictures.

Also das macht man in Unitest auch.

Also so Factory Boy oder Factories, um halt aber ja, aber diese Art, wie man in Pile-Test halt, dass man das quasi einfach magisch, dass man es halt in den Testaufruf mit reinschreibt, halt das, was man haben möchte, und ist es dann halt einfach da.

Das ist auch so natürlich so ein bisschen magisch.

Das gibt es in Unitest nicht.

Dann muss man was explizit machen.

Okay, 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 Contest und habe dann alle Funktionalitäten, die ich da brauche.

Ich löse das halt über Vererbung.

Also ich habe halt dann einen Base-Test, 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 Fixtures auch eher selten.

Ja, ich genau, ich habe auch viel, also in Projekt mit Unitests, dass ich dann halt so viele Test-Mix-Ins importiere oder das habe ich halt früher immer gemacht, die dann halt bestimmte Funktionalität bieten.

Und was ich jetzt aber inzwischen so mache, ist, ich erbe von Test-Case oder halt Transaction-Test-Case 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 Test Cases.

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 es funktioniert bisher.

Dynamische Importe klingt so ein bisschen.

Ja, naja.

Ich meine, manchmal muss man auch Sachen ausprobieren, manchmal sind sie super.

Manchmal stellt man irgendwann fest, war nicht so gut.

Muss man sich wieder ändern, aber es ist halt, ja.

Ja.

Was ja fast schon ein Stichwort wäre zum Sachen ausprobieren.

Ich hatte vor einiger Zeit 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.

Das Mitarbeiter können sich in- und auschecken 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 Weihnachts- und Silvester, also Heiligabend Silvester sind halbe Feiertage.

Das heißt, man hat, hier wird je nach Firma anders ausgelegt, aber in dem Fall war das, dass dann vier Stunden das normale Arbeitszeit wäre.

Und die ganze Logik lief und war auch, hat auch gut funktioniert.

Und da habe ich immer gemerkt, wenn ich irgendwas reflectern möchte, ich hatte jedes Mal die Hosen voll und habe mich halt wirklich nicht dran getraut, weil das halt einfach so unmöglich zu testen ist.

Und hab dann halt erstmal angefangen, ganz normal zu Fuß-Tests zu schreiben.

Also einfach zu schauen, ich setze den und den Case auf, also keine Ahnung, Mitarbeiter arbeitet, normal fünf Tage die Woche, also diese ganzen Datenbankobjekte erstellt.

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

Das ist ausgefallen, also die Vertretung und die Vertretung übernimmt dann aber noch anderthalb Tage, weil dann den halben Tag eine andere Vertretung da 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 mehr 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 Kind-Klasse 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.01.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 doch 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 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 Test Case hat?

Und tatsächlich glaube ich, 80% der fehlgeschlagenen Tests lagen daran, dass ich dann in der Nachimplementierung einen Bug hatte.

Ich glaube, ich hatte eine richtigen Implementierung, die ich damals noch vor vielen, vielen Jahren ohne Tests geschrieben habe, 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 hab 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 ein 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, lassen es beide programmieren und das eine ist halt das Testsystem vom anderen.

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 es halt schlecht, wenn das irgendwie schief gegangen ist.

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 es ist halt nicht so ganz klar, wo.

Testen ist alles schon ein bisschen dunkle Magie auch.

Also ich hatte gemacht, 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, dann trug die Test fehl.

Dann stand ich da natürlich, 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.

Ja, dann hat mir jemand erklärt, ich habe einen non-deterministischen Test geschrieben, also Test, der ein 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 gecheckt, 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 ohne dass man das jetzt beim Schreiben vielleicht so gedacht hätte, aber 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 dem 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 Anton.

Da gibt es ein sehr schönes Beispiel, das 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 Django war, immer wieder mal passiert.

Ich bin mir nicht mehr so hundertprozentig sicher, ich habe es länger nicht mehr selber erlebt, aber wenn man eine Aggregierung oder ein Annotate macht, dann Orderby, beziehungsweise nein, wenn das Model selbst in der Meta-Option, in Order By, der so ein standardmäßiges, eine standardmäßige Sortierung 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 bei 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 keinen XP-Order bei gemacht.

So, plötzlich schlagen irgendwelche Tests fehlt, nachdem ich auf Django 3.1 hochgegangen bin, weil der die Reihenfolge anders ist, weil es gibt es kein Order bei mehr.

Es gibt halt irgendeine Reihenfolge, die die Datenbank zurückgibt.

Okay, ja, ja, das ist ein Danger ist aufgefallen, ja.

Ziemlich abgefallen.

Ich habe auch erst gedacht, das kann doch nicht sein.

Also ich hab doch nur, ich habe Django hochgezogen, was ist denn da los?

Bis mir dann ein lieber Kollege sagte, schau mal, such mal nach Orderby in den.

Also Orderby

ist er echt rausgeflogen, das habe ich keinen.

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.

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

Immer, außer du machst Annotated Aggregate.

Ah, okay.

Da gibt es auch einen eigenen Eintrag dazu und das ist auch irgendwo im Ticket nochmal festgehalten und verlinkt, etc.

etc.

Ich bin da jetzt auch nicht 100% in den Details drin, ich bin halt nur drüber gestolpert, weil das war auch genau das mit der Reihenfolge.

Plötzlich war mein Element, das 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, damals noch sortiert war, dann steht man da plötzlich.

Ja.

Ja, und das mit der Reihenfolge von Tests 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 PyTests und bei Unitests anders, aber man kann halt mit einer bestimmten Option sagen, so für die Tests mal in umgekehrter Reihenfolge aus.

Wenn das schief geht, dann weiß man schon, dass man ein Problem hat.

Oder für die mal in zufälliger Reihenfolge aus, dann muss man es halt wahrscheinlich ein paar Mal ausführen und wenn es dann funktioniert hat, hat man vielleicht wirklich 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, schnell.

Die hat heute nicht schon ganz, ganz viele CPU-Serverview.

Genau, ja.

Ja, es gibt sogar noch ein Ding, XS oder so, mit dem kann man dann halt Sachen noch auf mehrere Rechner verteilen, aber wie 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 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 oder?

Also 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 die haben da inzwischen auch Optimierung gemacht.

Wenn man da genau die Agile irgendwie dran sitzt, dann.

Tatsächlich 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 lokalen doch mal manchmal ein bisschen schneller geht oder so eine Parallelisierung.

Bei dem längsten Projekt, das ich betreue, das ist eine interne 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, was vertretbar ist, das 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 jetzt wir reden sie wieder vom Django Unitest-Welt oder ich glaube, das ist insgesamt Unitest-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 wird.

Also eine Test-Klasse 10 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 Setup-Test Data.

Und da wird es in eine Transaction gewrappt.

Das heißt, die Daten werden nur einmal ausgeführt, also es ist auch eine Class Method, also es ist nur einmal pro Klasse, aber die kann man quasi recyceln.

Also bei jedem Testaufruf.

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.

Ich habe gedacht, ah, es ist 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 5 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

50 schneller.

Da gab es doch jetzt auch genau dieses Buch dazu, wie man Django-Tests spielt.

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 hab's und ich habe es auch so ein bisschen quer gelesen schon, aber noch nicht so.

Ja, da stehen viele coole Sachen drin.

Also auch ganz gut.

Nein, ich habe es wirklich, ich habe das ganze Kapitel doch gar nicht gelesen.

Aber da stehen auch viele interessante Dinge drin, ja.

Also zum Beispiel, dass man halt, ja, also auch Vergleich Unitest, PyTest zum Beispiel, der sagt da halt auch, ja, PyTests ist eigentlich schon cooler.

Bei vielen Kapiteln steht dran, so, das ist jetzt nur für Unitests 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 PyTests wie Unitests geben ja aus, wie lange sie laufen.

Aber Unitest ist so ein bisschen gemogelt.

Also viele Sachen kommen da nicht mit rein.

Da muss man halt, also auf einem Unit schreibt man halt Time davor, um halt zu sehen, wie viel hat es denn, wie lange hat es denn wirklich gedauert.

Und tatsächlich die Real-Time, wie lange hat das gedauert, ist halt das, was einer eigentlich interessiert.

Und da ist Py-Test 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, zu dem, das hat jetzt, solange hat der Test gedauert.

Und ja, also was er empfiehlt, was man halt am Anfang machen kann, ist, also man sollte erstmal gucken, 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 Pi-Tests geht das einfach Minus, Minus Durations und dann eine Zahl und dann kriegt man halt die Zahl langsamsten Tests einfach am Schluss ausgegeben.

Und bei Unitests muss man halt irgendwie Django-Slow-Tests installieren oder so.

Aber damit geht das in der Art auch.

Und dann den Testrunner ersetzen und dann kriegt man die halt auch ausgegeben.

Und dann kann man halt bei den Tests halt dann 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 da diverse Tools, mit denen man sich denn.

Also man kann einen C-Profile, kann man Ausgaben anzeugen, die man sich dann angucken kann, mit K-Cache-Grind oder naja gut, muss man sich, also 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 noch so ein Standard, weil man erzeugt halt viele User und so und da muss man halt auch.

Und die echte, echte Passwort-Hash, die echten Passwort-Hash-Agorithmen 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, möchte man es halt aber eher schnell haben.

Und dann, wenn man dann den MD5-Hasher nimmt, oder der ist halt nicht sicher, aber der ist auch mal.

Bei dem Hash 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 Mittelware-Antwort in den Settings testen.

Kannst du die Middleware dann einfach nehmen?

Nee, nee, das ist keine Middleware.

Du kannst den Passwort-Hasher setzen.

Ja, okay.

In den Settings setzen.

Du sagst dann halt nicht Passwort-Hasher, irgendwas von denen, importierst halt deinen MD5-Passwort-Hasher und schreibst halt den String zu dem Hasher einfach in die Config rein.

Fertig.

Ich meine, rein theoretisch brauchen wir auch gar keinen Passwort-Hasher.

Ich meine, du willst dich ja nicht einloggen in Tests.

Ja, ja, ja, keine Ahnung.

Ich weiß nicht, es wird halt empfohlen, in 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.

Ach, gemacht.

Keine Ahnung.

Genau, das war so das Erste, was er empfiehlt.

Dann sagt er sowas wie, ja, irgendwie vor allen Tests wird irgendwie die Datenbank serialisiert.

Man kann jetzt an den Datenbanksting ranschreiben, also für die Testdatenbank Serializable Doppelpunkt Falls oder so auch eine Config-Option.

Und dann wird das halt nicht gemacht.

Man braucht das eigentlich fast nie.

Es gibt ganz selten Testfelder, die sowas benötigen, aber eigentlich braucht man das nicht und macht auch Sachen schneller.

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, also wie ich weiß nicht, wie du das machst mit Files, wenn du halt irgendwelche Bilddaten oder so testest oder so, 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 Cleanup Scripts geschrieben.

Genau, Dinger geschrieben.

Nicht Cleanup 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-Route wieder aufgeräumt oder so.

Ich weiß gar nicht gar nicht mehr genau, wie ich das gemacht habe.

Aber auf jeden Fall habe ich da halt irgendwie Aufwand reingesteckt und dachte so, oh, das war ätzend.

Und es gibt Diod 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 es ist halt viel schneller, weil es ist halt in Memory.

Es funktioniert halt genauso, aber es halt landet hinterher gar nichts auf der Platte.

Und wenn man viel mit Files macht, dann ist es halt sofort deutlich schneller.

Ja, das war auch so ein Ting, das ist wahrscheinlich echt gut.

Das ist sehr praktisch.

Dann gab es noch so Salary-Optimierungen.

Da kann man auch ein Memory-Backend verwenden.

Und naja, man muss halt gucken, dass man halt AlwaysEager auf True setzt und auch noch irgendwas anderes, weiß ich mehr genau.

Ja, sowieso diese ganzen Async-Task-Dinger, da gibt es dann halt Jungle Q, das will ich mir mal angucken.

Salary habe ich letztens wieder, ah, Salary, Salary!

Ja, genau, genau, damit genau dann mal.

Euch vielleicht auch.

Mich hat es auf jeden Fall vor ein paar Tagen gebissen, mal wieder, als ich irgendwie dachte, so irgendwie seltsam ruhig hier so alles.

Irgendwie passiert das zu wenig auf dem Produktionssystem.

Wie kommt denn das?

Und ich hatte gerade irgendwie released und gucke dann halt so in die Logfile und sagt so, was sind die ganzen Satellitests?

Wo sind denn die hier?

Wieso?

Was?

Warum werden da keine Saturny-Tests mehr ausgeführt?

Und dann habt ihr so ein bisschen gegoogelt und dann ja, jetzt, ich glaube 447 war das oder so, hat irgendeine Regression, eine böse Regression drin gehabt, dass halt die Salary Broker URL oder so aus den Settings nicht mehr benutzt wird.

Oh.

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 downgegrad auf 4.46 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 noch 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 noch länger laufen.

Und wenn man den Aufruf der unteren Funktion, also der unterliegenden Funktion einfach mockt, dann spart man natürlich einen ganzen Laufen Zeit, weil der halt dann nicht versucht, eine API anzusprechen und man irgendwie die API mocken muss oder keine Ahnung was, sondern 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 neu antennen, also einmal muss man ganz kurz erklären, was überhaupt Services sind, vielleicht für alle Menschen, die es noch nicht so benutzen haben.

Okay.

Also Django hat von sich aus ja keine, bringt da kein Pattern mit, wo man Logik hinpackt.

Es gibt Manager für Datenbankqueries, 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.

Utils, helpers.

Nee, nee, das ist auch Utils, immer wenn du ein Modul hast, das Utils heißt.

Tatsächlich auf der auf der Kopenhagener DjangoCon letztes Jahr.

Jetzt muss ich meine ganze Applikation direkt weg drin, das weißt du mal.

Ich weiß, ich habe selber solche, aber ich weiß, also allehands.

Weil das Problem ist halt, dass, naja, was sagt dir das, wenn da, wenn du bei irgendjemandem siehst, da liegt halt ein UTIS-Modul rum, was ist da drin?

Als möglicher Unsinn.

Ja, weißt du halt nicht.

Ja, genau.

Das ist gar nicht so gut, wenn nur der Zack rumliegt und weiß nicht, was das ist.

Tatsächlich gab es da auch einen Vortrag auf der letzten DjungoCon in Kopenhagen, wo dann auch ein paar Franzosen, glaube ich, drüber geredet haben, dass die halt das Konzept vermissen, dass das nicht offiziell in Doku drin steht, mach 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.

Und dann auch, ich meine, das ist halt so eine Art Best Practice.

Das hat kein offizielles Django Pattern, aber ich glaube, das gilt inzwischen als Best Practice.

Korrigiere mich, wenn du es anders siehst, aber.

Nee, ich weiß, weißt du es nicht, ich weiß jetzt, es ist aber nicht diese Geschichte, wo irgendwelche Leute versucht haben, den ORM so ein bisschen wegzuabstrahieren.

Der gab es nicht.

Genau, auch auf Django News, die haben auch da Werbung gemacht.

Auch die haben das auch irgendwie Services genannt, aber ich glaube, das war was anderes.

Jetzt ist gegen das Wadi das Projekt irgendwie Maintaining a Jungle Project over 10,000 Commits oder so, was hieß das.

Die hatten so ein paar ketzerische Ideen, die wollten absichtlich ein bisschen Unruhe stiften, glaube ich, im positiven Sinne.

Ja, nö, ist ja gut.

Die sind mir, glaube ich, mal angucken.

Kenne ich gar nicht.

Also wie gesagt, es waren halt insgesamt 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ühler später immer schwerer rein 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 es halt sehr cool fänden, wenn dieses Django-Ding 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 nicht, 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 mocken.

Also man kann die aktuelle Zeit mocken, was sehr praktisch ist.

Also was sagen, heute ist nicht heute, sondern irgendwann anders.

Montag.

Und man kann aber auch einen Mock-Block verwenden.

Das heißt, man kann einfach dann sagen, alles was in diesem Mock-Block passiert, wenn da eine bestimmte Funktion aufgerufen wird, führt er die nicht aus, sondern gibt einen festen Werkzeug.

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, also ich meine, das ist eigentlich, 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 Code oder deinen Testcode verbessert, weil dadurch, dass halt die unterliegende Funktion einen festen Rückgabewert haben, wenn da jetzt ein Fehler drin ist, dann tangiert das halt nicht die anderen Sachen, sondern die unter Funktionen, die ja hoffentlich auch getestet sind, failen dann isoliert und man hat dann nachher nicht irgendwie 50 gefällte Tests.

Man muss erstmal anfangen zu suchen, sondern im Optimalfall, wenn alles isoliert genug ist, fällt genau der Test, der nicht mehr das tut, was er, das bringt, was er möchte.

Und diesen Doppel-Win, das fand ich echt ziemlich neat, das nochmal so zu realisieren.

Ja, ja, nee, klingt gut.

Also ich packe meistens meine Logik irgendwie so in den Modell-Layer, mehr oder weniger.

Genau, oder beziehungsweise dann halt in Mixins, die dann halt irgendwie.

Models aufblähen.

Ja.

Wenn das dann zu lang wird, stecke ich die halt in andere Files und importiere die dann aus Models PY dann halt da rein.

Genau, aber ja, ja, ich weiß auch noch nicht so genau.

Ich muss mir dann, ich muss mal die Vortrag angucken.

Genau.

Es gibt verschiedene Meinungen zu, glaube ich, ja.

Ja.

Definitiv.

Das ist wahrscheinlich auch der Grund, warum das noch nicht in Djangodoku gelandet ist.

Ja, bei

Tuscro sagt ja auch, dass total Katastrophe für Fettmodels, 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 mit der Datenbank oder so.

Vielleicht sind sie dann am Model.

Ich mag das auch.

Also ich würde jetzt nicht sagen, ich mache jetzt, da ist alles rein, 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, aber wir hatten nochmal ganz kurz über das Mocken geredet und ich glaube, Mocken ist auch was, 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 hatte, 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 Relative.

Das ist halt, ja.

Ja, genau, und vielleicht ist das eins der Probleme.

Also ich hatte das schon öfter mal mitbekommen, dass gerade Menschen, die irgendwie viel Coverage erreichen wollen, haben sich irgendwie sich dann so mit vielen Mocks 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 so solche Sachen, also wirklich abgefahrener Gott.

Ja, also mock die ihr überhaupt irgendwas oder findet ihr das anstrengend?

Oder wann macht man das?

Wieso?

Also ich benutze das sehr häufig und ja, muss man 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.

Man kann nicht mehr so gut.

Das heißt, die externen Antworten von Dingen, die du nicht im Test eigentlich abbilden kannst, die musst du dann tatsächlich machen.

Die muss man

emulieren bocken, denke ich.

Das geht gar nicht anders.

Ja gut, das sind eine Abfrage von externen API, die kann man sich tatsächlich vorstellen, dass das sinnhaftig sein kann, ja.

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, wieder der, ja.

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

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

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 jetzt 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 irgendwann natürlich von der Realität.

Ja, also das User-Endpack oder sowas, das kann man ja auch in Frontend weiterdenken, was man halt irgendwie alles dann mocken kann.

Habt ihr viel Frontend schon getestet irgendwie?

Was gibt es da alles bei Mota und?

Nee, nicht wirklich viel, ja.

So Unit-Tests im Frontend, das ist ja, glaube ich, hat sich inzwischen so Just als der Standard etabliert so ein bisschen.

Reden wir jetzt von JavaScript oder reden wir von normalem Django-Template?

Ich werde Frontend direkt immer schon bei JavaScript.

Ja, ja, eh, aber.

Ja, leider, leider.

In der Python-Welt auch, aber vielleicht ist das Test das derselbe Thema.

Ja, meintest du denn Django-Templates?

Nein.

Nein, ich meine tatsächlich, JavaScript, Tomuta und was man da alles so bauen kann.

Ja, also ich würde sagen, da gibt es ja halt eben den Unterschied zwischen End-to-End-Tests, also Cypress oder weiß ich nicht, was Leute da noch verwenden.

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

Ja, also ich habe damit auch nicht so wahnsinnig viel Erfahrung, ehrlich gesagt.

Doch meistens für Djungle-Seite.

Ja, also entweder baut man halt gute, richtig gut funktionierende Apps schon von sich aus oder man braucht halt Tests.

Ja, aber man kann halt auch tatsächlich andersrum anfangen und kann sagen, man baut zuerst seine Tests.

Das ist man dann Test-Driven Development und wenn man erst die Tests hat, die alle fisch gehen und dann den Code baut, was halt 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 Anwendungen überhaupt machen sollen oder macht, um dann Tests zu bauen zu können, wo die dann diese hypothetische Anwendung irgendwie stimmen kann.

Und das alleine 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, Test-Driven zu entwickeln.

Aber ja, da ist die Idee ja im Grunde, dass du genau erst immer den Test schreibst und dann erst den Code.

Und 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, es gibt ja die Django Shell Plus zum Beispiel, in den Django Extensions, wo man halt die ganzen Modelle schon drin hat, sozusagen.

Das gibt es halt auch in einem Jupyter-Frontend.

Und man hat dann quasi so eine Umgebung wie in der Shell Plus, bloß halt mit dem ganzen anderen Jupyter-Kram drumherum.

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.

Wenn man so funktionieren machen möchte, die machen.

Ja, weil oft Sachen muss man halt irgendwie ausprobieren.

Das geht nicht, da muss man es irgendwie anders machen.

Und damit geht das eigentlich tatsächlich sehr, sehr, sehr schön, während man halt, wenn man jetzt das tatsächlich direkt in den 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.

Klick, klick, klick, klick.

Und das ist halt alles immer ein bisschen schwieriger.

Und im Notebook hast du das halt, da änderst du dann wieder deinen Code fürs nochmal die Zelle aus und weißt dann, okay, jetzt passt es.

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 an auch Tests zu schreiben.

Manchmal stelle ich dann noch was um, weil es irgendwie dann einfacher ist zu testen oder so, aber oft ist es dann auch mehr oder weniger dann schon so fertig.

Das heißt, das Test-Driven ist quasi gar nicht erst Testschreiben bei dir, sondern doch eher so Experimente machen in so einem Notebook, die halt so lange durchgehen, bis du halt was, was gerade getogen hast.

Also so ein bisschen Learning by Doing oder ja, man könnte jetzt auch sagen, ausprobieren und bis jetzt irgendwas funktioniert.

Aber da sag ich mal, in Notebooks ist diese Iterationsstreife relativ kurz.

Es ist relativ kurz.

Das ist der große Vorteil.

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

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

Ist das, was quasi dann im Applikationscode in einer Jungware 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 dürfen, die wir da machen sollen?

Es gibt da ein paar Leute bei uns, die das machen.

Ich persönlich mache es nicht.

Ich bin da ähnlich wie Jochen, dass ich denke, so 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.

Also Debugger heißt also, welche Entwicklung schon geben nutzt du?

Tycharm von IntelliJ.

Und ich habe mir das irgendwann mal angefangen anzugewöhnen.

Das Schöne ist halt, du kannst halt dann mit den 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 STRG ist, also Speichern drückt und 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 Zwischenstate in eine neue Variable speichern, weitermachen.

Das ist ein sehr interessant anders.

Das 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 mehr abgucken mit den Notebooks, weil du da halt auch immer diese Iteration treffen hast.

Und auch, also wir benutzen ja VS Code VS Code Jochen 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.

Für mich persönlich, also mir geht es ein bisschen so, wie das verstanden habe euch beiden auch.

Ich weiß halt am Anfang meistern nicht so genau, was nachher rauskommt.

Also die meisten Sachen, die man ja so zu testen, 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 er mehrere Methoden, wie sehen meine internen Methoden aus?

Ich habe da noch nicht so ein Bild davor, 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 gehe dann, 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 das sonst 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, ach, das könnte man ja 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 immer noch keine Gewinn-Test geschrieben, ich bin das 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 testen, weil du hast.

Aber du hast jetzt gerade einen Bias drin gehabt, du hast gesagt, die richtige Struktur.

Du hast gesagt, dass er die Struktur, die man gut testen kann, die richtige wäre.

Ja, okay.

Eine bessere, 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 postieren.

Okay.

Und das zum Beispiel hat mir, als ich dann angefangen habe, mich intensiv in Unitests zu beschäftigen, halt sehr geholfen, auch nochmal wirklich beim Code schreiben auch zu überlegen, wo soll das denn alles hin?

Also wenn ich halt weiß, ich möchte das irgendwie isoliert und vernünftig, also ich möchte nicht nachher drei Stunden über Tests nachdenken und irgendwelche wilden Fälle zusammenbauen, sondern ich möchte es ja einfach, so eine Funktion, die macht eine 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 für, 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 Pythaguru 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 erst auch mein erster intensiverer Kontakt mit TDD und ich habe ihn da im Nachgang auch gefragt und hab gesagt, hey, guck mal, ich arbeite so und so, was sagst du dazu?

Ich meine, ne, du hast dir hier den.

Und 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 testbarer Code 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 dir an und schreibst einen Test, der per se fehlen 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 erstmal, 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 ja 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, der Test ist versehentlich grün.

Also false positive.

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 Init-Pie weggekommen aus dem Testordner, wie auch immer.

Und naja, dann sind die halt plötzlich mal ausgeführt.

Das Projekt hat damals, glaube ich, 800 Tests, die 50 Tests für die Rechnungslegung, die sind 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 es 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 eigentlich ganz nett, dass man wirklich mal guckt, so, hey, funktioniert das denn wirklich?

Weil es kann ja wirklich sein, dass man ein Test einfach, dass der, ja, dass der versehentlich funktioniert.

So viel gemockt oder so, man weiß es nicht.

Und ja.

Ja, nee, absolut.

Spannendes Thema.

Ich würde dich gerne noch ein paar Getränke hier testen.

Was haben wir denn?

Wir haben mit der Liste.

Ich glaube, die Liste sind wir ganz gut, oder?

Durch.

Wir sind durch?

Nein, das ist noch nicht.

Wir sind voll vorbereitet, wir haben eine Liste.

Du hast ja selber geschrieben, ich kann gar nichts lesen.

Du kannst ja schon mal die Liste lesen.

Ich kann ja vielleicht nochmal gerade, also ich bin immer noch ganz begeistert von dem Sweet Up 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-File-System legen.

Es gibt zum Beispiel mit Docker oder 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 ist halt anders als Postgres oder was man dann.

Ich wollte gerade sagen, kann man damit denn so PostCAD-Funktionalität testen?

Wenn ich jetzt zum Beispiel, im Postgres habe ich jetzt so was wie Indexes bauen oder sowas und sagen wir so.

Ja, ja, ja, das funktioniert alles.

Es ist halt das drunterliegende Fallsystem, was dann halt nur noch im Hauptsprecher ist.

Das ist immer schlecht.

Ich muss ja gestehen, wir hatten ja erst geplant, das bei dir daheim zu machen und ich hatte gehofft, dass da zu viel das Buch herumliegt.

Nicht an meinem Blick rein.

Achso, nee, ich hab's nur elektronisch.

Ich habe es nicht genau.

Aber ja.

Okay.

Lässt sich sicher sonst auch machen, irgendwie, muss man gucken.

Ja, nee, ja, stimmt.

Ja, ich bin inzwischen fast komplett umgestiegen auf irgendwie elektronische Bücher, weil, ja, praktisch.

Und ich habe es nicht immer dabei.

Der einzige Grund ist, dass du halt keinen Platz mehr im Regal.

Alles voll, fällt schon alles raus.

Doppeltreifach, kennt ihr kennt das auch?

Meere Stapel an Bücherlagen irgendwie im Regal.

Ja, ja, beim meisten Bücherregalen ist bei uns immer mindestens eine Lage noch dahinter.

Ja, genau.

Lass mal überlegen, was war denn da?

Gab es sonst noch irgendwie interessante Dinge, in den Buch drin standen?

Ja, es gibt dann noch irgendwie auch so grundsätzliche Dinge.

Test parallelisieren bringt sehr viel.

Migrationen bringen auch viel, wenn man die squasht.

Oh ja.

Das ist dann 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 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 Block gehabt.

Der hat einfach gewagt, an seinen Blogartikel zu einem Buch zu verwurstern.

Könnte man davon lernen.

Ja, genau.

Ansonsten, ich weiß 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, dass wir überlegen, ob ich irgendwas mit Data Science, also da ist es auch so, da macht man auch viel Tests, aber das ist auch alles sehr ähnlich.

Alles Unit-Tests, die dann irgendwie die einzelnen Test Cases brauchen.

Eine Sache, die ich noch ganz interessant finde, das geht wieder so ein bisschen Richtung 100% Test Coverage.

Mich auch mit jemandem unterhalten und der meinte, er ist gar nicht so ein Fan von Unit-Tests.

Natürlich braucht man die.

Er meinte, der hat das so ein bisschen mit den drei Musketieren verglichen.

Also Athos, der ist so ein bisschen langweilig, aber der gehört hat deshalb der Chef.

Die brauchst du halt einfach, kannst du 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 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 dann das Frontend drin hat, wo man dann wieder in einer ganz Django-fernen Welt, oder was heißt Django-fern ist, es ist halt dann tangiert Django nicht direkt, sage ich mal.

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.

Es ist natürlich meistens ein bisschen mehr Setup, weil man halt sich 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 jemanden, der, keine Ahnung, ne, ich habe eine Rechnung, enthalten die dies und jenes.

Also 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 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, nee, 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 die Demikation-Test.

Keine Ahnung, wo weiß ich auch nicht.

Oder das hast du gerade von den drei Musketieren gesprochen und er ist ein einziges Musketier erwähnt.

Genau, also die Functional-Test ist Porthos, der coole, der Pirat.

Ja.

Und die Integration-Test ist dann Aramis, glaube ich, heißt der letzte.

Die anderen beiden waren?

Ja, stimmt, du hast ja schon.

Also Artos, Porthos, Aramis und dann D'Artagnan gehört ja nicht so richtig dazu.

Ich muss aber, nicht, der, der das Beispiel gebracht hat, mich jetzt hautweis durcheinander bringe, aber Arthus ist auf jeden Fall der langweilige Unit-Test.

Dann Portos, glaube ich, war das coole, vielleicht waren das auch die End-to-End-Tests, das weiß ich nicht mehr genau.

Ich glaube, also D'Artagnan oder Portos, weil die sind beide so, ne?

Und genau, Aramis ist dann Integration-Test, sprich, wo man dann 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.

Das ist total cool, das zu haben, aber man hat halt auch irgendwie ziemlich viele Schare rein damit.

Und ja.

Der Wind kommt, der wird die Tests gerade haben.

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 die drei Musketiere und nicht die vier.

Ja, ja.

Königin der Kunde oder sowas, ne?

Die entscheidet dann tatsächlich, wie es mit dem weiterläuft.

Mit den dreieinhalb, vier.

Ja, fällt euch noch was einzutesten.

Ich teste, glaube ich, noch gleich ein Wein.

Ja, genau.

Ich meine, nö, ich glaube, wir sind eigentlich so halbwegs durchgekommen und so.

Die erste Folge draußen war gar nicht so verkehrt.

Also ich hoffe, ihr habt genervt mich jetzt im nächsten Mal.

Was auf Phonex draus macht.

Alles klar.

Ja, vielen

Dank auf jeden Fall für die Einladung.

Ja, vielen Dank, dass ihr auch schon wart.

Sehr schön.

Mein erster Podcast.

Und ja, war echt cool, hat Spaß gemacht.

Ja, schön, dass ihr alle reingeschaltet habt.

Vielen Dank, dass ihr da wart.

Schreibt uns auf Hallo.peisenpodcast.de und bleibt uns gewogen.

Bis zum nächsten Mal.

Tschüss.

Tschüss.

Ciao.