Wir hatten ja mal zusammen ein lustiges Problem, wo man also man glaubt es lustig, lustig. Es hat uns die Nerven geraubt. Coding Boys Dein Podcast wohnt im Softwareentwicklung und aktueller Technews. Herzlich Willkommen. Was? Die neue Folge vom Callingbuddies Podcast startet und damit heiße ich euch auch alle herzlich willkommen und zwar dich, liebe Zuhörerin, lieber Zuhörer und dich natürlich auch Tino schön, dass du wieder hier bei mir bist oder dass wir hier zusammenkommen für
eine neue. Folge ja alles gut bei mir. Schöne Einleitung, hat mir sehr gut gefallen. Danke, danke. Hast du deinen Pool bereit? Also bei mir ist es gerade heute ein bisschen wärmer. Ich hoffe, du sitzt in deinem kleinen bisschen. Ich hoffe du sitzt zu deinem kleinen Pool und. Ziemlich schön, so eine Podcast Folge aus dem Pool heraus aufnimmt, wäre auf jeden Fall eine nette Sache. Die. Realität ist aber, ich sitze wie immer an meinem Schreibtisch. Das ist unfassbar warm.
Komm live Gold einmal im Podcast aufnehmen aus dem Pool, dann im Winter oder so. Dann wird er genauso ein Eisbad. Nee, das klingt nach einem coolen Ziel. Das können wir auf jeden Fall mal. Bei uns Vorlebe sehr gut. Bist du denn so badetyp? Ja, auf jeden Fall. Wer ist wer ist kein Badetyp na gut, es gibt. Bestimmt Leute, die das nicht so geil finden, aber ich finde es so im Pool chillen oder mehr ist
schon verdammt cool. Also ich muss sagen ich gehe im Alltag relativ wenig baden, auch wenn man irgendwie so ein Sehnerähert oder so irgendwie mache ich es nicht so oft, deswegen frage ich besser, also ich mache das gerne, aber ich mache es irgendwie nicht oft, da ist dann wieder die Frage macht ich würde. Gerne los dein Zimmer zu verlassen. Die Außenwelt zu betreten. Das Problem ist, weil das Wetter gut ist, da musst du ja irgendwie trotzdem zum See hinkommen.
Und wenn es dann aber mega warm ist. Also du schwitzt dich ja spätestens auf dem Weg vom See nach Hause wieder tot. Dann bleib mal lieber gleich da. Genau gar nicht erst die Reise antreten. Ich war letztes Wochenende tatsächlich mal wieder in einem Freibad okay und aber Insekten. Kleinen sag ich mal kleinen Dorf, Kleinstadt, so eigentlich nur so auf Durchreise gewesen.
Aber es war so warm, dass man sich dachte, ah, wollen wir nicht jetzt irgendwie mal kurz ins Freibad, so mal ne Stunde schwimmen, so weil es n bisschen abkühlen. Und da war es so schön leer, dass es richtig geil war. Im Freibad fand ich das richtig gut, weil ich verknüpf das eigentlich mit Menschenmassen klein schreienden Kindern. Dass es gar nicht so entspannt ist. Aber das das war ziemlich gut. Aber ich verstehe auf jeden Fall
deine gedankliche Hürde dabei. Ja, so schlimm ist es dann auch nicht. Aber so kleiner kleiner Witz am Rande, ja, hast einen schönen Arschbombe vom Fünfer gemacht, der Klasse, es gab keinen Fünfer, leider. Sonst natürlich, das war das war echt doppelten Rückwärtssalto, vorweg noch und dann im Finale Nahspumm ist ja eigentlich immer das Beste, weißt du immer schön reinspringen ins Wasser fand ich, fand ich immer findig und fand ich immer super OK.
Aber das Ding ist halt einfach vom Beckenrand durft man nicht springen und hätte ich das gemacht, hätte mich wahrscheinlich der Bademeister direkt rausgezogen. Fliegst gleich raus. Hausverbot für immer. Das Risiko war einfach zu groß. Schön, ja gut, so bisschen badetalk, das ist doch schön. Hoffentlich sind jetzt alle erfrischt, dann können wir jetzt bestimmt, bestimmt können wir
jetzt ins Thema die. Eine oder andere Person, die das gerade aus dem Freibad hört und diese Podcast Folge, ist für dich. Tolle Vorstellung, tolle Vorstellung auf jeden Fall. Genug off Topic, lass uns mal fachlich werden. Worum geht's denn heute? Genau, lass mal starten. Heute wird es mal wieder eine schöne, saftige Cleancode Folge geben. Und es wird diesmal darum gehen, dass Cleancode ist ja OK, es geht um cleanen Code, also sauberen Code, der skalierbar
ist. Alles wichtig dabei sollte man aber nicht vergessen, dass natürlich auch Tests sehr wichtig in der Software sind. Ich sehe dich schon lachen und strahlen. Das ist natürlich eines deiner Lieblingsthemen, finde ich aber gut, wir sollten auf jeden Fall mal über Testing in Bezug auf Cleancode reden. Ich also wirklich. Ich also testen. Ich weiß nicht warum, aber so über die letzten Jahre, dass mir das so richtig ans Herz gewachsen, das Thema. Das, was alle hassen. Und wir werden jetzt
herausfinden, warum. Genau. Also ich muss auch sagen, wie ist das Thema auch sehr, sehr wichtig ich. Kenne aber auch die Momente, die vielleicht viele auch noch haben, so dieses gar keine Lust jetzt einen Test zu schreiben. Aber es hat einfach schon zu oft gezeigt in meiner sag ich mal entwicklungssoftware entwicklungskarriere, dass es ohne einfach nicht cool ist. Und wenn du das so ein, zweimal durchlebt hast, dann weißt du
auf jeden Fall Test schreiben. Ich habe das ja auch manchmal, dass man einfach an den Punkt kommt, wo man sich denkt, ja, ich weiß nicht, jetzt erstmal, weil es jetzt einen Test schreiben und also du hast ja auch manchmal, es kommt ja auch immer ein bisschen darauf an, wie komplex dann dieser Test ist und dann manchmal auch so ein bisschen anstrengend. Aber das soll keine Ausrede sein, denn Test ist wichtig.
Das haben wir auch in der ein oder anderen Big Fails Folge Big Software Fail Folge gemerkt, das stimmt, wichtig ist. Und manchmal haben da auch Tests gefehlt und deswegen. Die der bis jetzt noch immer, oder? Wollt mir die zu weit Ausweis sein? Ah der Appell doch mal aber. Jetzt soll es ja so n bisschen. Es gibt ja verschiedene Arten von Tests, es gibt ja Unit Test, es gibt Integration Test, e to e Test.
Es gibt ja verschiedene Kategorisierungen von Tests und in dem speziellen Fall wollen wir ja uns ein bisschen mehr auf die Unit Tests konzentrieren fokussieren. Möchtest du ganz kurz einmal abstecken, was denn so ein Unit Test ist? Ja, das kann ich gerne mal machen. Also Unit Tests sind im Prinzip. Tests für kleine isolierte Einheiten, beispielsweise eine einzelne Funktion. Und dafür gedacht, quasi die Funktionalität dieser einzelnen Funktionen quasi abzutesten.
Das heißt, man ist quasi sehr low Level unterwegs und testet isoliert die kleinsten Bestandteile einer Software ab und das macht das ganze Halt auch so wichtig, weil dann kannst du quasi von unten. Hinauf, sage ich mal gewährleisten, dass deine Software funktioniert. Ja. Der einzige Nachteil dabei ist, das kann man ja ganz kurz mal erwähnen, um das noch abzustecken. Du hast natürlich jetzt kein Verbund an Funktionalitäten, sondern wirklich nur.
Sag ich mal die einzelnen Funktionalitäten abgetestet, das heißt wie jetzt komplexere Aufgaben im Verbund funktionieren, ist damit nicht abgedeckt. Dafür gibt es dann andere Testebenen. Aber lass uns heute mal wirklich in Sachen cleancode mal auf Unit Test eingehen. Genau, also wirklich so eine, quasi eine Einheit wie du meintest ne Klasse ne Funktion und das ist erstmal so der Scope find ich gut, find ich gut. Genau, dann wär eigentlich so n bisschen die Frage, was gute
Tests eigentlich ausmacht. Also wenn wir jetzt davon, wir reden ja vom Cleancode, wir reden von Tests, also reden wir davon, was sind denn eigentlich gute Tests oder wie sollte man denn vielleicht Tests schreiben, damit man am Ende auch nicht nur einfach irgendwie eine Testabdeckung hat, sondern dass man natürlich auch eine gute Testabdeckung hat bzw. Tests, die diese Abdeckung schaffen.
Das ist natürlich wichtig, weil es ist dir bringt halt nichts, wenn du richtigen Murks schreibst, sag ich jetzt mal. Und dann also blöde Tests hast, die aber am Ende quasi. Auf die du dich nicht verlassen kannst. Ne. Das heißt was sind eigentlich gute Tests? Ja, also das Wort oder dieses dieser Stichpunkt zu sagen, ich möchte mich auf meine Tests verlassen, ist halt auch schon genau der Richtige. Also du musst es ja irgendwie schaffen.
Zuversichtlich gegenüber deiner Funktionalität der Software zu sein, anhand oder mithilfe von Tests, dass du sagst, OK, ich bin mir sicher, so sicher wie man sich sein kann. Dass meine Software richtig funktioniert und dafür helfen Tests halt ungemein, gerade wenn es später auch um Refactoring geht, dass du halt immer noch siehst. Ah guck mal, wenn du testen es ja immer noch grün. Also ich bin immer noch zuversichtlich, dass alles funktioniert wie es soll und ja, wie erreicht man das?
Da gibt es halt, ich denke da hat jeder so ein bisschen seine eigene Philosophie als Entwickler. Aber so n paar Punkte gibt es wo glaub ich also bei denen wenig Widerspruch kommen sollte hoffe ich. Und das sind sowas wie Lesbarkeit und Wartbarkeit. Also ich glaube jeder möchte, dass die eigenen Tests von anderen Entwicklern schnell verstanden werden können, das heißt, sie sind gut lesbar, man kann schnell durchdringen, worum
es geht dabei. Ja, das ist nämlich auch der Punkt der Verständlichkeit und der Skalierbarkeit, dass das Ganze natürlich auch nicht komplett auswuchert. Das heißt, dass man einfach auch n guten Stil hat, wie man seine Tests schreibt, dass das Ganze wirklich. Leserlich verständlich bleibt und skaliert, weil ich mein jeder, der Mal mit Unittest gearbeitet hat und wenn nicht,
dann hoffentlich bald tut. Dass quasi so unittest ne sehr sehr hohe Anzahl erreichen, sobald die Software n bisschen komplexer wird, hat man ja hunderte, wenn nicht sogar tausende unittests. Ja. Ohne Probleme und. Das zu überblicken, da sind nämlich genau diese Punkte dann wirklich entscheidend. Ja, definitiv. Was ich auf jeden Fall auch, also diese diese Lesbarkeit, Verständlichkeit gehe ich total mit, das ist glaube ich sehr wichtig.
Ich hatte auch mal einen Fall, da saß ich an einem Test, den ich mir durchgelesen habe, weil ich wirklich verstehen wollte, was diese Software tut. Auch noch mal kurz Punkt Testdokumentation Testdokument Codedokumentation kann man sehr gut über Tests erreichen. Aber nur, wenn die Tests auch aussagekräftig beschrieben sind, also aussagekräftige nicht Namen, sondern wirklich Beschreibungen haben.
Meistens sind das ja eher dann Sätze, mit denen man die Tests beschreibt und da hatte ich dann auch mal irgendwie einen Test, der mir irgendwie da stand irgendwas drin, wo du dachtest okay, ich weiß gerade überhaupt nicht, was da von mir gewollt ist und der eigentliche Name wäre am besten gewesen, sowas wie. Weiß nicht root to next Page und Button Click oder irgendwie sowas. Weißt du das also um das sich mal vorzustellen, aber da stand dann irgendwie sowas drin wie zum Beispiel.
Ich, ich kann es dir gar nicht mehr sagen, aber es war so ne. Es war so so komplex, es war halt eine eine sehr sehr technische Beschreibung, auch auf der Seite wo du dir dann also technisch im Sinne von. Du musstest eigentlich den Code verstehen, um zu verstehen, warum der Test so geschrieben ist. Anhand des Namens. Das war ziemlich schwierig an der Stelle und deswegen ist es halt auch von dieser Verständlichkeit, die du
meintest sehr sehr wichtig. Hab ich auch schon auf aus eigener Hand. Mitgekriegt, dass das. Unabdingbar ist eine gute, gute Testnamen auch zu vergeben.
Absolut was ganz kurz, was mir da direkt einfällt bei dem Beispiel oder diesem dieser den Fall den du da hattest ist natürlich weil du meintest Testabdeckung ist auch ein riesen Punkt verstehe ich, ich kenne oder habe auch viele Leute kennengelernt die sagen ja du musst eine Testabdeckung von 100% erreichen, weil irgendwelche Prozesse das auch brauchen, wenn zum Beispiel. Sage ich mal functional safety
und sowas. Eine Rolle spielt also, wenn du halt wirklich so ISO Norm dahinter hast hinter deiner Entwicklung, aber ich verstehe halt nicht was bringt mir eine hundertprozentige Testabdeckung, das heißt jede Codezeile wurde angelaufen über die Tests und habe dann aber solchen Fall, dass ich den Test nur verstehe, wenn ich mir den Code angucke, also dann habe ich zwar alles abgedeckt und.
Höchstwahrscheinlich, oder? Die Wahrscheinlichkeit ist hoch, dass die Tests nicht sehr aussagekräftig sind, bis hin sogar, dass sie eigentlich nur die Implementierung abtesten und nicht mehr wirklich die Funktionalität, weil ich bin der Meinung, zumindest aus meiner Erfahrung heraus ist ne hundertprozentige Testabdeckung nicht notwendig um zu gewährleisten, dass die Software gut abgetestet ist. Also da gehe ich auf jeden Fall auch mit. Wichtig an der Stelle ist glaube ich auch zu sagen.
Dass manchmal auch gerne solche Vorgaben kommen, wie zum Beispiel hundertprozentige Testabdeckung in Bezug zum Beispiel auch auf Unit Tests. Und das ist zum Beispiel auch wieder schwierig, weil es gibt ja, wie wir schon am Anfang gesagt haben, wo wir jetzt nicht drauf eingehen wollen, aber noch mehrere Schichten von Tests und die Kombination aus den ein oder anderen Testarten ergeben, die Halt einfach eine gute
Testabdeckung, sage ich jetzt. Mal. Und dann ist es aber auch wieder wichtig zu sagen okay welcher Test kümmert sich wo drum und welcher Test ist sinnvoll, weil es bringt halt auch zum Beispiel nichts, wenn du.
Zum Beispiel Dopplungen. Hast also im Sinne von ja, ich, ich hau jetzt zum Beispiel den einen Test, den mach ich hier an der Stelle und dann mach ich auf einer anderen Ebene zum Beispiel Test ich das gleiche noch mal in Grün ab, ne, also das ist zum Beispiel auch blöd, da ist es dann zum. Beispiel Grün Abtesten ist immer wichtiger.
Du weißt, was ich meine. Das Sprichwort also das ist halt auch n wichtiger Punkt und ich finde ne Faustregel ist an dieser Stelle einfach, dass man sich sagt, OK wie gut und das hatte ich ja eben schon gesagt, kann ich mich auf meine Tests verlassen, weil es bringt ja halt nichts, wenn du sagst, du hast irgendwie eine hundertprozentige Testabdeckung.
Aber diese also auf dem Blatt Papier, aber trotzdem hast du hinterher eventuell noch Bugs oder so in deiner Software drin, weil es geht ja manchmal wenn du ich muss jetzt ein bisschen ausholen, aber wenn du jetzt an diesen Punkt kommst wo du sagst okay ich möchte zum Beispiel, ich habe meinen Code und manchmal kommt ja dann dieses okay, dann testen wir jetzt einfach den Code, der da ist einfach noch ab mit ganz vielen Tests, dann hast du vielleicht eine hundertprozentige
Testabdeckung gewährleistet, aber jeder Bug der da drin ist, den hast du mit Abgetestet. Und damit hast du zwar 100 prozentige testabdeckung, kannst dich aber eigentlich nicht auf deine Tests verlassen. Dass dein Code wirklich einwandfrei funktioniert. Und das ist halt so n bisschen so n Trade off, wo man sagt, die höchste Priorität meiner Meinung
nach sollte haben. Kannst du dich auf deine Tests verlassen, kannst du zum Beispiel sagen, wenn ich irgendwas neues Feature implementiere und die alten Tests grün laufen und die neuen Tests sozusagen auch noch grün laufen, funktioniert dann alles noch so wie vorher? Sind die Bugs auch raus und und und. Und das das ist, das ist n viel viel wichtiger Punkt meiner Meinung nach als eine hundertprozentige Codeabdeckung Testabdeckung auf Papier zu haben.
So das ist und der Punkt ist auch schon schwierig genug, also das überhaupt so erstmal hinzukriegen ich. Hatte halte ich auch die Erfahrung gemacht, dass es denn so hieß ja okay. Wir haben hier noch ein paar Zeilen, die nicht angelaufen wären und dann wurden halt Tests geschrieben, die einfach nur irgendwie in so einem Case reinlaufen. Wo du dich fragst, also der sagt nix aus dieser Test. Wir versuchen nur irgendwie diesen Prozess zu befriedigen. Da gab es dann halt zum Beispiel
sowas. Du hast eine IF Bedingung und hast so quasi optional einen Code. Und dann hieß es okay es muss aber immer, wenn es ein IF gibt auch ein Els geben. Denkst du so OK, aber ich habe kein Elswall, das ist wirklich nur so ne Ergänzung. Optional weißt du unter einer gewissen Voraussetzung führst du noch meinetwegen paar Zeilen Code aus und dann war es sowas
wie. Es wurde quasi der Elsfall Gecoded ohne Inhalt mit einem Kommentar OK aus dem und dem Grundprozess machen wir das so, damit du den anlaufen kannst sozusagen, obwohl da nichts drin passiert, da dacht ich mir so why also du bläst ja dann das ganze einfach nur auf um zu sagen, ja nee, es muss auf jeden Fall ein Aids geben, Oh und jetzt wollen wir auch noch 100% Coverage, das heißt wir müssen
irgendwie da auch noch rein. Und das das ist, das sind halt so Sachen, wo ich mir denke, okay, das habe ich damals schon nicht verstanden, würde ich selbst auch so nicht machen. Und ein anderer Punkt, den können wir auch mal diskutieren, um ein bisschen von der Coverage wegzukommen, ist dieses ein Test darf nur ein Assert haben, also du möchtest nur eine Sache überprüfen, Protest. Da dachte ich mir so anfangs okay verstehe ich, weil das spielt in die Lesbarkeit und
Verständlichkeit rein und. Aber ich glaube, in der Praxis macht das wiederum auch nicht so viel Sinn. Also es kommt darauf an, wie komplex der Test ist. Aber ich denke, man sollte da eher in eine Richtung gehen, dass sich eine, wie soll ich sagen, so ein Konzept oder eine Funktionalität abteste und ich mehrere Sachen prüfe, aber wenn ich beispielsweise sage, ich habe eine Funktion und die gibt mir irgendwelche. Zurück, sagen wir mal ein Objekt
mit 5 Attributen oder? Keine Ahnung warum 5 sauer. Und ich würde jetzt einen Test schreiben, wo ich mir jedes Mal dieses unter gewissen Eingaben mit dieses Objekt oder die Daten hole und schreibe jetzt 5 Tests um die einzelnen Attribute abzutesten. Da denke ich mir so, das macht alles nur viel schlimmer, also warum sollte ich das tun? Du meinst. Ja, nicht doch. Genauso sagen ganz kurz in diesem einen Test. Den benenne ich, denn weiß ich wie, dass ich halt oder
gegebenen? Voraussetzungen, also Eingaben, die die richtigen Daten bekommen beispielsweise. Und dann kann ich doch alle 5 Attribute darin abtesten, dass die richtig sind. Ja. Also im Endeffekt ist der Test sehr lesbar.
Im Endeffekt ist es ja so, dass also wenn man jetzt noch mal ganz kurz sagt, OK, wenn man jetzt nicht wüsste, was n assert oder n expect ist, das sind ja jetzt 2 häufige Begriffe, dann sag es ja beispielsweise bei einer, ich nenn es jetzt einfach mal ne Additionsfunktion, dann kannst du ja zum Beispiel nur mal sagen, du rufst die Additionsfunktion mit 2 und 2 auf und erwartest dann am Ende, dass es 4 ist. Das heißt deine Funktion, das Ergebnis deiner Funktion.
Erwartest du es cirtest oder expected du, dass es 4 ist? Dann am Ende unter den bestimmten Bedingungen?
Das ist ja wäre ja zum Beispiel einfach mal ein ganz ganz sehr, sehr einfacher Fall an der Stelle, das heißt, das wäre jetzt sozusagen diese Expectations, das heißt, oder dieser ist dieser, dass du sagst, also nur um das noch mal kurz zu erklären, du hast eine Ausgabe von deiner Funktion, also irgendwas was da rauskommt, und du erwartest, dass du etwas dann am Ende erhältst nach dieser Durchführung. Ja, dass die Erwartungen auch der Realität entspricht.
Genau am Ende genau und genau. Genau. Und ich finde zum Beispiel finde ich gut was du sagst, wenn du jetzt zum Beispiel, wir können ja mal ein Beispiel nehmen, zum Beispiel. Du hast n Konstruktor und von dem Objekt und dieser Konstruktor nimmt zum Beispiel weiß ich nicht 2 Attribute entgegen, aber intern in deinem Objekt hast du noch weitere Felder, die aber anhand von den Daten, die du von außen bekommen gefüllt werden.
Und dann willst du ja ZB. Reicht es ja zu sagen, wurde also vom Test her wurde dieses Objekt richtig konstruiert, construkted und dann kannst du ja genau anhand von deinen Eingabeparametern von diesen 2 die du hast zum Beispiel deine 5 Attribute am Ende überprüfen, ob die wirklich richtig so gesetzt wurden, wie du es dir vorstellst. Wie deine Erwartung ist von dem Construkten des Objektes zum Beispiel nur mal so als Beispiel um sich vielleicht etwas. Sehr ähnlich zu meinem Beispiel. Und.
Dann macht es halt wenig Sinn, da jetzt mehrere Tests draus zu machen. Das finde ich halt noch einen Punkt. Ich glaube in dieser ganz traditionellen Cleancode Welt. Es redet man schon so von. Want, Assert, Protest. Was ich schwierig finde. Also dann lieber sagen, also man kann also ja eine Funktionalität, ich würde jetzt nicht mehrere Sachen, zum Beispiel ich erstell diesen Konstruktor, diesen dieses Objekt, was du meintest, ne mit dem Konstruktor.
Man möchte erstmal prüfen, ob die Werte, die da intern noch gesetzt werden, richtig sind. Dann würde ich in dem Test nicht noch irgend ne Funktion von diesem Objekt aufrufen und sagen, jetzt guck ich ob das und das da auch noch passiert, weil das sind dann schon wieder 2 getrennte Funktionalitäten in
meinen. In meiner Betrachtung sage ich mal auf jeden Fall, das würde ich testweise trennen, aber nicht die Attribute einzeln da irgendwie abfragen, weil dann weiß ich nicht, ja gut, mag vielleicht auf dem Papier cool aussehen, wenn man dann 5 statt einen Test hat, aber. Das bringt keinen Mehrwert, im Gegenteil, es wird nur noch schwieriger zu warten. Naja, auf jeden Fall. Also im Endeffekt wäre ja quasi das Pound Down dazu von dem klassischen was du meintest, dass man zum Beispiel sagt.
Beim Konstruieren des Objekts ist Attribut a richtig gesetzt, beim Konstruieren des Objektes Attribut b richtig gesetzt und so weiter und sofort ne anstatt zu sagen das Objekt wird richtig
konstruiert, sozusagen. Ja, also das ist ja, warum sollte man denn das Einzeln aufteilen, da gehe ich auf jeden Fall total mit, würde uns aber auf jeden Fall mal interessieren, ob das zum Beispiel jetzt auch liebe Zuhörerin, lieber Zuhörer, bei dir zum Beispiel an ob du da eine andere Sichtweise auf die Dinge hast oder ob du da mitgehst. Das ist ja auf jeden Fall ein sehr spannendes Thema und da kann man sich auf jeden Fall. Gut drüber unterhalten und auch einfach mal in den Austausch
gehen. Genau. Aber wenn du gerade sagst cleancode ne. Klassisch cleancode, da gibt es ja auch irgendwie so n bestimmtes Prinzip um zu sagen, OK, woran können wir uns denn zum Beispiel lang hangeln, um vielleicht auch so nen Kleinen. Sagen wir mal, wie sagt man so eine Eselsbrücke zu haben?
Um zu gucken, OK, was machen denn erstmal so einigermaßen gute Tests aus, mit denen man erstmal sozusagen starten kann, um vielleicht auch dann seine Erfahrungen zu sammeln, weil am Ende, wie wir auch schon selber gemerkt haben, Erfahrung ist auch wichtig und man muss da auch irgendwie auch ein bisschen seinen Weg finden. Ja, mit dem ganzen cleanco Thema kam halt auch dieses Akronym First auf. Das hat eigentlich ein ganz paar coole Punkte.
Also First steht jetzt jeder Buchstabe quasi für ein ganzes Wort und was halt quasi eine Eigenschaft eines Tests beschreibt. Die also. Diese Eigenschaft, die wünschenswert ist, quasi. Also kann man schon sagen wie du meintest. Man nimmt das, wieso eine Art Checkliste und. Da können wir. Ja mal drauf eingehen. Also First wäre ja der erste Buchstabe ein F. Und F ist ja steht für F. Im Prinzip also schnell. Und das klingt immer so n bisschen selbstverständlich.
Ja, Tests müssen schnell sein, ja OK, klar, schnell ist immer gut so ne. Aber es geht eher darum, dass die Tests schnell sein sollten, damit man sie häufig ausführen kann. Nicht, um der schnell zu sein. Hey, guck mal, meine Tests laufen viel schneller als
deiner. OK sollte Performance Sachen sind auch spannend, aber es geht wirklich in erster Linie darum zu sagen sie sollen so schnell sein, dass ich sie häufig ausführe, weil es gibt ja auch höhere Testebene wie wir gesagt haben und meistens kann man davon ausgehen, dass damit auch im Verhältnis die Zeit ansteigt, die es dauert, quasi die Tests laufen zu lassen, was ja logisch ist, weil wie gesagt es ja verbünde sind, die man dann testet.
Und Unit Tests sollten auf jeden Fall sehr schnell laufen. Das heißt, die dürfen nicht viel Zeit in Anspruch nehmen und sollten auch sehr oft durchgeführt werden. Weil genau weil ich glaub, das kann man sich ganz gut
vorstellen. Angenommen es dauert lange und jetzt sagt jemand in, während du entwickelst, lässt du bitte immer deine Tests laufen und ergänzt Deine Tests um neue Fälle und Prüfst dann wieder ob noch alle laufen, dann refacto das und dann lässt du noch mal alle laufen und guckst ob noch
alles in Ordnung ist. Und wenn du das so in deinen Workflow integrierst und ich muss sagen wir beide lassen die Tests, also alle Tests wirklich sehr oft laufen auf Unit Test Ebene. Und das darf einfach nicht lange dauern, weil das hemmt dich daran, sie laufen zu lassen, was logisch ist, weil es nervt ja irgendwann, wenn es ewig dauern würde und deswegen ist fast das F von First wirklich ein sehr wichtiger Punkt, den man berücksichtigen sollte und wenn
man irgendwie einen Flaschenhalster drin hat, das auf einmal die Unit Tests wesentlich länger brauchen, dann sollte man nicht den Weg gehen und zu sagen naja gut, dann ist es so, dauert halt jetzt 20% mehr oder so von der Zeit. Und auch nicht weglaufen. Okay auch nicht weglöschen.
Finde ich gut, sondern denn wirklich das im Auge behalten und auch angehen das Thema. Also du kannst ja rein theoretisch auch, es gibt ja auch verschiedene Frameworks, die dann vielleicht jetzt den Kohl nicht fett machen, weil du dann heißt so OK anstatt. Sagen wir mal 10 Sekunden laufen dann die Tests nur, also nur 6 Sekunden.
Man denkt sich dann ja, ja, OK oder vielleicht nur noch, also je nachdem wieviel Tests man hat ne nur um das jetzt mal n bisschen greifbar zu machen, ist vielleicht nicht der Hit und nicht die Welt, aber nichtsdestotrotz weißt du wie du
schon meinst. Wir entwickeln in zum Beispiel ne neue neue Klasse oder neuen Service regelmäßig und dann kommst du an n Punkt wo du sagst OK ich lass nur diese Testsuite laufen von dem entsprechenden Service beispielsweise oder der Klasse. Und dann sagen wir aber auch regelmäßig, OK, jetzt werfen wir mal wieder die gesamte Testfeed
laufen. Wenn du das aber immer am Tag machst und sagen wir mal ich, ich weiß gar nicht, wie oft wir die Tests am Tag laufen lassen, aber es sind bestimmt schon 100 mal. So würde ich jetzt einfach mal in den Raum werfen und dann hast du aber n Unterschied von 4 Sekunden mal 100 sind 400 Sekunden, das sind fast 10 Minuten am Tag wo die Tests laufen nur lokal bei einem selber während der Entwicklung was an sich ja schon relativ
viel ist und. Dass es halt sind Kleinigkeiten, aber nichtsdestotrotz ist es halt einfach auch. In in in guter Punkt auch mal zu überprüfen. Zum Beispiel, ob man auch vielleicht ein anderes Framework nutzen kann, was auch schneller ist, weil das hatte ich zum
Beispiel auch schon mal. Also noch mal kurz Kleines Off topic, sind jetzt wieder andere Tests, die liefen aber mal in der Pipeline. Damals glaube ich 4 Stunden lief unsere Pipeline bis alle Tests durch Waren und da ging es jetzt nicht um unittest, weil die sind sehr sehr schnell, sollen aber auch um zum Beispiel It to e Tests und die sind meistens relativ langsam und dann haben wir uns. Daran gesetzt und haben das geschafft.
Auf unter eine Stunde zu kommen, was in dem Fall eigentlich immer noch lang ist, aber nichtsdestotrotz halt viermal so schnell halt, also mehr als viermal so. Schnell und. Bei keine Ahnung 10 Commits am Tag ist das schon. Ist das schon ein Ding? Ja genau, du kommst halt an den Punkt, dass du irgendwann Thema Pipeline dir sagst. So ja OK, wo sollen denn die
Tests laufen, in welcher Stage? Und da ist es ja schon wünschenswert zu sagen, Na ja, also in so viel Stages wie möglich ja, also es ist immer gut, die Tests laufen zu lassen. Wenn du aber am Punkt bist wo es ewig dauert und du es dann halt nicht mehr schaffst. Sage ich mal oft und zeitig zu integrieren, dann nervt das Halt und dann muss man das Thema angehen. Aber auch was für Deffox. Ja, genau, da gibt es ja auch dabei. Da können wir denn da weiter drüber quatschen.
Aber es ist auf jeden Fall ein richtig wichtiger Punkt zu sagen, die müssen schnell sein, und zwar im Sinne von, damit man sie selbst, also dass man motiviert ist, sie selbst oft laufen zu lassen. Ich denke, so kann man das ganz gut zusammenfassen, guter Punkt, guter Punkt, magst du den nächsten Buchstaben? Nehmen genau der nächste Punkt ist ja von Fürst das I, also independent, also quasi unabhängig. Das heißt, Tests sollten
unabhängig voneinander laufen. Das heißt, ein Test sollte nicht vom Ergebnis von anderen Tests abhängig sein und sie können halt auch in beliebiger Reihenfolge ausgeführt werden. Und das klingt jetzt so, ja, warum sollte das nicht der Fall sein? Ist aber ganz witzig, weil wir hatten ja mal zusammen ein lustiges Problem, wo man also man glaubt es lustig lustig. Es hat uns die Nerven geraubt. Du hast recht. Im Nachhinein ist es immer lustig. Ja, ja, egal.
Auf jeden Fall war das ein Spaß, auf jeden Fall das also das, das bescheuert an der ganzen Sache ist.
Ja, dass sowas relativ anstrengend ist, herauszufinden, also kann anstrengend sein und da war es dann im Endeffekt so, dass wir jeden Test, also wir haben einen Test geschrieben, jeder Test, den haben wir einzelnen laufen lassen, haben dann sozusagen die Funktion implementiert und der Test war dann grün, dann haben wir den nächsten Test gemacht und so weiter und dann kamen wir zu dem Punkt, wo wir gesagt haben,
okay, wir haben alle. Sind geschrieben, die Implementierung dazu gemacht, ist alles einzeln gelaufen. Jetzt lassen wir noch mal alle Tests laufen bevor wir committen und auf einmal war die Test Suite rot und da waren dann so
weiß ich nicht. Ich sag jetzt mal 4 von den 5 Tests die wir geschrieben haben waren rot und dann haben wir uns gefragt, was ist denn jetzt los so und wir haben Ewigkeiten gebraucht bis wir gemerkt haben, dass wir ein Emitter genommen haben und diesen Emitter der uns Daten emittiert hat. Den haben wir sozusagen, den mussten wir für den Test immer wieder instanziieren was aber bedeutet, dass du auf dem gleichen Channel, ich hoffe jetzt kommt wieder mit.
Daten imitierst und dann aber nicht genau weißt okay welche
Daten kriege ich denn jetzt? Das ist ungefähr so, wie wenn du jetzt zum Beispiel wenn du jetzt 50 Leute auf dem auf der gleichen, auf dem gleichen whatsapp Kanal Nachrichten schicken, du weißt ja nicht mehr wer dahinter steht, so ist das jetzt die eine Person die andere was auch immer, du kannst es nicht mehr zuordnen und ungefähr so kann man sich das ungefähr vorstellen und dann mussten wir halt gucken okay wie kriegen wir es jetzt hin diese Tests unabhängig voneinander?
Machen. Und da haben wir dann. Im Endeffekt gibt es dann auch bestimmte Möglichkeiten, dass du zum Beispiel so solche Emitter wieder.
Du, du lauscht der auf einem Channel, dass du im Endeffekt dann wieder sagst, OK, ich ich anzapribbe ich lausche nicht mehr auf diesem Channel, ich möchte davon keine Nachrichten mehr empfangen und gehe dann quasi wieder neuen Channel ein, mache einen neuen Channel auf, wie auch immer das ist so, ich hoffe das war jetzt nicht zu Deep Dive, aber es hat dazu geführt am Ende um das Ganze auf den Punkt zu bringen, dass wir halt die Tests einfach nicht nebeneinander oder zusammen
hintereinander wie auch immer laufen lassen konnten und das ist dann am Ende ein Problem. Genau weil dieser Punkt unabhängig ist halt so wichtig man, ich meine. Aus diesem Grund versucht man ja auch Sachen zu isolieren.
Also du versuchst einen Freischnitt in deiner Software zu erreichen um einzelne Klassen oder Funktionalitäten abzubilden und testen zu können und dann kommst du ja irgendwann an den Punkt innerhalb deiner Software, schont die Außenwelt, nenne ich es mal zu. Isolieren und dann beispielsweise zu faken? Ja, mit Stupsmogs, was es da alles gibt. Das Problem ist, wenn du mit sowas anfängst oder halt dir auch sagst, ja ich brauch jetzt irgendwie jemand der was ermittelt.
Jetzt baue ich mir so ein Fake Emitter der Daten sendet. Dann kommst du halt wie bei uns so schön an den Punkt. Relativ schnell wo Side Effects entstehen, weil auf einmal brauchen mehrere n Fake Emitter wie in unserem Fall oder Halt irgendwie Daten aus einer. Simulierten Schnittstelle, sage
ich mal. Und dann musst du halt aufpassen, dass du dann dich in anderen Tests quasi falsche Daten reingibst, wie du da gar nicht möchtest, weil du versuchst ja wie gesagt so eine Isolation zu schaffen, dass du ganz genau sagen kannst, Pass auf, in dem Test kriegst du diese Daten in dem anderen Test Test b kriegst du dann auch Daten b. Wenn jetzt aber im ersten Test die anderen Daten ankommen, dann läuft er natürlich rot und genau das ist ja dann wie du es so schön erklärt hast mit dem
Fallbeispiel. Passiert.
Und dann fragst du dich aber erstmal, ich lasse die einzeln laufen, ich lasse Sie im Verbund laufen rot, dann lasse ich 23 laufen, die sind grün, warum sind die aber wenn es jetzt 5 sind rot weiß und dann kommst du halt an dem Punkt wo du richtig wahnsinnig wirst und deswegen achtet darauf, liebe Zuhörer, liebe Zuhörer, immer schön isoliert und auch wirklich eine saubere Ausgangsbasis zu schaffen, wenn der Test läuft für jeden Test weil das sind dann sogenannte flaky Tests,
wenn sie manchmal grün laufen und manchmal rot und das ist halt eigentlich das Schlimmste, was passieren, was passieren kann, weil genau dann hast du diese wichtige, diesen wichtigen Punkt, den ich mal meinte. Am Anfang der Folge ist nicht mehr erfüllt. Du kannst dich nicht mehr auf deine Tests verlassen und das ist eigentlich das Schlimmste, was passieren kann, weil deine Tests sind die Grundpfeiler deiner Software, auf die du dich verlassen kannst.
Dass deine Software funktioniert und wenn die nicht mehr da sind, also deine Grundpfeiler des Hauses nicht mehr da sind, dann bricht logischerweise irgendwann ein Haus zusammen und das ist halt dann ein Problem, genau so viel zum Thema Unabhängigkeit oder Independent, was ist denn das nächste? R. Repeatable also, dass sie quasi wiederholbar sind insofern, das haben wir sogar schon halbwegs
andiskutiert. Es geht halt darum, dass deine Tests wiederholbar ausführbar sind, das ist richtig, ich glaube, der Satz war richtig, und zwar. Das ist beispielsweise nicht nur lokal läuft oder nicht nur in der Pipeline läuft, sondern überall da, wo du die Tests laufen lassen möchtest, sie auch ausführbar sind. Das heißt, sie können wiederholt ausgeführt werden, zum Beispiel in den verschiedenen Stages deiner Pipeline und.
Wenn du sagst bei mir lokal, dann komm bitte und pushe ich das, dann läuft es in der Pipeline die gleichen Tests noch mal. Das soll einfach daran erinnern, dass man versuchen muss so externe Faktoren zu minimieren oder auszuschalten. Dass sie halt so. An sich laufend, sage ich mal. Da hatte ich auch mal n super interessanten Fall und zwar wir hatten ja in einem Team eigentlich alle die gleichen Voraussetzungen, alles war
gleich eingerichtet. Und dann auf einmal liefen aber bestimmte Tests auf der einen Maschine, also bei mir zum Beispiel liefen die und bei wem anders liefen die einfach nicht mehr. Und also im Sinne von unterschiedliche Ergebnisse, oder?
Nee, die also, die das Testtrailwork wollte nicht mehr richtig starten irgendwie, oder ich, ich krieg es nicht mehr ganz, also die testen auf jeden Fall durchgelaufen und die waren auf jeden Fall alle rot und das hatte aber n bestimmten Fehler und dann den kannst du natürlich nachgucken und dem Ganzen auf den Grund gehen, nur das bescheuert an der ganzen Sache ist ja es fließt Zeit ins Land, du musst gucken wieso ist es jetzt so, dass meine Tests unter eigentlich den gleichen
Bedingungen nicht mehr laufen? Verhältnis zu anderen Tests, die auch eigentlich unter den gleichen Bedingungen laufen. Und dann musst du erstmal checken, OK, was ist denn jetzt
vielleicht passiert? Wurde irgendeine Software geupdatet, irgendwas was dazu geführt hat, dass es nicht mehr richtig läuft und das ist manchmal auch n ganz Schönes, wo man sich da rein bewegt und absolut absolut, deswegen ist es zum Beispiel auch wichtig zu sagen okay wenn jetzt irgendjemand im Team zum Beispiel mit jemandem
zusammenarbeitet, irgend. Eine Ahnung, irgendein Update von irgendeinem Teil irgendeiner Teil Komponente macht dann auf jeden Fall kommunizieren, aufschreiben, irgendwie was auch
immer. Kannst du auch so weit gehen, dass du sagst, wenn du alleine arbeitest und du hast vielleicht 2 verschiedene Rechner und arbeitest hier und da hast das gleiche Repository und beim einen geht es nicht um, beim anderen geht es schon, du hast aber keine Ahnung vor 3 Wochen mal irgendwas geupdatet und weißt aber gar nicht mehr was es genau war auch blöd also sowas wichtig. Kleine Sachen sein, immer darauf achten, auf gleichen Versionen arbeiten und so weiter. Ja, absolut.
Also diese externen Faktoren spielen doch öfter rein als man denkt. Warum ich nachgefragt hab ist, weil es kann ja auch genauso sein, das war die Testsuiten starten und vielleicht vereinzelte Test rot sind auf einem anderen System wo du dir auch wieder denkst hä, wie kann das denn sein? Aber wenn du halt auch so. Externe Abhängigkeiten, die zum Beispiel systemrelevant sind, also irgendwelche Systemfunktionen und.
Lokal hast du Windows PC laufen und deine Pipeline läuft auf einem Unix System, dann kann sowas halt auch schon klingeln sag ich mal definitiv und dann musst du halt dafür sorgen, dass es unabhängig von diesen externen Faktoren auf allen Maschinen läuft. Ja, genau das sollte auf jeden Fall auch sehr hohe Prio haben. Auf jeden Fall ja. Wichtiger Punkt. So, nächster Punkt, der nächste Punkt. Da sind wir beim S angekommen und zwar Self Valley Dating oder Selbstvalidierend.
Da ist es so, dass Tests sollten entweder erfolgreich sein oder fehlschlagen. Ne. Also sollte jetzt zum Beispiel auch nicht so sein, dass man noch ne externe Überprüfung braucht im Sinne von zum Beispiel du lässt nen Test laufen, kriegst n Testergebnis raus und du musst jetzt sozusagen manuell. Noch mal selber überprüfen und bestätigen.
OK, ich sag jetzt mal die Zeichenkette, die ich jetzt wirklich erwartet hab, die da rauskommt, das ist auch die ne, also irgendwie noch mal von von außen oder irgendwie drauf gucken n Test sollte so geschrieben sein, dass du am Ende mehr oder weniger n boole schen Wert hast, der dir sagt OK
läuft. Der Test funktioniert, er ist grün oder der Test ist fehlgeschlagen, er ist rot, da geht nicht so, das ist auf jeden Fall relativ wichtig, weil du musst ein schnelles Feedback bekommen von den Tests. Ohne dass da noch irgendwie irgendwas on top kommt. Ja, absolut, ich. Diesen Punkt hat sich in das
erste Mal gelesen. Hab ein bisschen merkwürdig mit diesem, du musst ein booleschen Rückgabewert sozusagen haben, also mir ist absolut klar gewesen warum klar, weil die Tests laufen und man sagt immer grün oder rot, also true oder false und du willst ja auch zum Beispiel wenn ein Test irgendwie rot läuft, dass wenn abgebrochen wird oder so nicht weitergemacht wird. Also du brauchst ja n Ergebnis ne und du willst auf der Stelle auswerten können, ob die Test
erfolgreich waren oder nicht. Was mein Clammer dabei war ist, dass mir dachte, wie schaffe ich es n Test zu schreiben. Der nicht True oder false am Ende zurückgibt, also dass der überhaupt nicht selbst validierend ist. Dann ist mir aber relativ schnell klar geworden, ja gut, man verwendet ja Test Frameworks und die geben dir ja diese Struktur, dass du genau dahin kommst. Du könntest ja jetzt auch genauso, das klingt idiotisch, aber um mal zu verdeutlichen, warum also dass es auch anders
geht? Du könntest ja die Funktion aufrufen und dir einfach konsolenausgaben prinden und dann? Gucken, ob expectations quasi, also deine Erwartung, dass es was auch wirklich zurückkommt, das ist idiotisch, ne, deswegen nutzt du ja zum Beispiel so ne Assertfunktion, die dann einfach true oder fal zurückgibt oder wie auch immer sie denn heißt, in welchem Testframework auch
immer. Aber das ist halt genau der Punkt am Ende und ich glaube, wenn man einfach aktuelle gute Test Frameworks nutzt, dann ist dieser Punkt relativ schnell abgehandelt und zwar im sehr positiven Sinne. Also weißt du, wie ich das meine? Weil ich weiß erstmal so hä also hä wie wie soll das ohne gehen? Aber man ist halt einfach auch so dieser Bubble drin, dass der denkst du ja, warum sollte ich das ohne machen, ne?
Was ich, was ich noch so n bisschen damit assoziiert habe, vielleicht fällt das nicht so richtig darein, ist aber auf jeden Fall mir auch schon häufiger mal vorgekommen und ist vielleicht auch ein bisschen ein blödes Problemchen bei Tests, weil wenn du zum Beispiel einen Test schreibst und mal als kleines Beispiel, du hast ein Array mit dem Buchstaben, also aus Strings. Buchstaben AB und C da drin.
So und jetzt hast du zum Beispiel Tests, die dir überprüfen, ob zum Beispiel diese 3 Sachen da drin sind und wenn die da drin sind ne habe gesagt, wenn wenn dein Array deinen Erwartungen spricht, dann ist es in Ordnung, das heißt mal blöd gesagt, der Test sagt der Buchstabe A im Array drin als Element B und C und wenn das der Fall ist, dann ist True. So, und dann ist mir zum Beispiel so ein Fall, hatte ich mal ähnlich, jetzt ist ein konstruiertes Beispiel, aber wenn du. Dagegen so genau.
Aber aber wenn du jetzt zum Beispiel in dieses Array noch ein d reinpackst, dann läuft der Test ja trotzdem grün, weil du ja nur überprüft ist AB und C drin, obwohl das eigentlich vielleicht an der Stelle. Nicht korrekt ist, wenn noch d drin ist. Und das ist so n bisschen. Vielleicht hat das nicht ganz was mit Selfie Dating zu tun, aber du erwartest ja etwas und sagst OK, das ist true. Und am Ende ist es trotzdem true, weil du ja nur ne
Teilmenge Überprüfst. Ne und das ist halt auch manchmal so n bisschen schwierig, da kannst du jetzt hingehen und sagen ja dann überprüf halt die Länge des Arrays OK ist auf jeden Fall n valider Punkt an der Stelle. Nur. Manchmal kommt man in solche Kleinen fallen rein. Das ist natürlich dann, dass der Test nicht spezifisch genug ist, weil er ist ja grundsätzlich nicht falsch. Wenn du also klang für mich eher nach einem Test, so ist AB und C enthalten, ja.
Vielleicht noch an den Stellen, die du vorgibst. So ein erster Position 2.3. Aber wenn es natürlich exakt dieses Array sein soll, dann fehlt da natürlich der Punkt und dann würdest du den Test weiter in grün laufen lassen können und alles mögliche reinschreiben. Da hast du natürlich recht und es ist ein absolut klassischer Fall, wer hat das noch nicht gehabt, dass er da einen Test nachschärfen musste. Aber er ist guter Punkt, ist ein guter Punkt.
Was haben wir denn noch jetzt? Lass mich mal first. Also du hattest gerade. TT war timely, timely. Was steckt dahinter im Endeffekt? Sagen wir mal so, das Ganze geht jetzt in eine Richtung von einer Methode, die wir beide sehr, sehr gerne verwenden und auch Werbung dafür machen. Denn Timely bedeutet, dass der Test rechtzeitig geschrieben wird und rechtzeitig in dem Sinne, dass er am besten noch befestigt.
War der Code geschrieben, wurde geschrieben wurde das heißt es existiert nicht die Implementierung von meinem gewünschten Verhalten und ich habe schon den Test, der dieses
Verhalten überprüft. Ja und das Ganze, diese Philosophie wird ja durch TDD getragen, also Test Driven Development, dazu haben wir auch schon eine Podcast Folge gemacht und da würde ich jetzt auch nicht so ausführlich mal drauf eingehen, nur noch mal die Werbung, liebe zuhören liebe Zuhörer, falls sich das Thema Rente interessiert, schauen wir bei unseren vergangenen Folgen nach.
Da haben Fabi und ich mal über TDD gesprochen und auch, wie wir das im Arbeitsalltag verwenden, weil wir halt ja sehr strikt, man kann es nicht immer zu 100% machen, das würde ich nie behaupten, aber schon strikt nach TDD arbeiten. Weil nur das noch mal ganz kurz als Teaser für die Folge Test Driven Development ist ja im Prinzip so zyklisch aufgebaut, dass ich halt erst den Test schreibe. Der ist dann rot. Also er soll auch wirklich rot
sein. Das heißt meine Software hat diese Implementierung nicht, um diese Funktionalität abzubilden, dann implementiere ich die Funktion und zwar auch nur so um den Test grün laufen zu lassen und danach kann ich das Ganze im dritten Schritt noch mal refacto und schaue, dass der Test immer
noch grün ist. Und da gibt es ja auch so die Three Laws of. Tdd Ich hoffe, die heißen so, dort ist mir irgendwie gemerkt, dass du halt, wie ich gerade schon meinte, dass es erst den Test gibt, beispielsweise wäre ein ein so ein Gesetz sage ich mal, bevor die Implementierung da ist und 2. Zweites Gesetz ist, was ich wichtig finde und das ist auch tricky, auch immer noch für mich selbst, dass du sagst, es gibt quasi auch nur diesen Test, was
ich gerade implementieren möchte, weil wer kennt das nicht, du hast diese Gesamtfunktionalität im Kopf und sagst okay Test 1, da müssen wir das überprüfen und danach schreiben wir Test und überprüfen das. Das wäre eigentlich so gesehen auch gar nicht nach dem Prinzip so. Du sollst ja quasi einen Test schreiben und dir dann dafür die Implementierung überlegen und das ist das dritte Gesetz. Implementiere auch nur. Damit dieser Test grün ist, nur das nicht da.
Auf der anderen Seite wieder denken, ja gut, aber gleich schreib ich ja noch n Test weißt du aber weil das soll ja gewährleisten, dass du halt diese diese jetzt wollt ich testabdeckung sagen, es geht aber nicht um Testabdeckung, sondern diese Gewährleistung, dass du dich auf deine Tests verlassen kannst. Extrem pushen und ich finde oder ich spreche jetzt mal für uns beide, dass wir da auch diese Erfahrung gemacht haben über die Jahre, dass.
Auch extrem pusht diese. Zuversicht definitiv also. Im Endeffekt geht es ja vor allem finde ich, immer bei Tdd darum. Das vielleicht zusammenzufassen, wenn du vorher deine Tests schreibst, dann konzentrierst du dich halt auf die Funktionalität, die du eigentlich haben möchtest. Wenn du deine Tests nachgelagert schreibst, dann kommst du ganz ganz schnell an den Punkt, dass du nur das Testest, was schon implementiert ist.
Das heißt, du hast deine Implementierung, da du dich interessiert, eigentlich gar nicht mehr, was da genau implementiert wurde, sondern nur noch, dass es abgetestet wurde und demzufolge hast du vielleicht über Bescheid. Fischkäses im Vorfeld gar nicht nachgedacht hast, gar nicht überlegt, was sollte meine Software denn eigentlich können
oder meine Funktion? Und wenn eventuell Bugs drin sind, dann werden die manchmal dann halt auch blind einfach mit getestet und das ist ja im Endeffekt genau der Punkt. Man will nicht den Code testen, sondern man will Tests für die Funktionalität der Software, was die Software tun soll schreiben und dass da hilft Tdd einfach ungemein und ich habe auch schon mit einigen Leuten darüber geredet, dass es dann im Endeffekt heißt ja. Glaube ich nicht und so weiter
wie gesagt, probiert es mal aus. Es ist ein deutlich, es ist echt ein Unterschied und wenn man das nicht glaubt, dann muss man es einfach auch mal ausprobieren. Anstrengend am Ende oder so viel Real Talk muss man auch betreiben, es ist nicht einfach das so umzusetzen, aber es macht sich auf jeden Fall bemerkbar, dann genau da bin ich ganz bei dir. Und wie wir mal sagen, je früher man anfängt damit und je früher man übt, desto besser. Ja, absolut, absolut und.
Noch noch n bisschen Real talk, bevor die Folge beenden zu dem Thema. Wie gesagt, wir würden uns jetzt auch nicht hinstellen und sagen, du musst zu 100% nach TDD
arbeiten. Es gibt immer Fälle, zum Beispiel wenn ich jetzt so ganz schnell n bisschen Rapid Prototyping betreibe und ich will ganz schnell was ausprobieren, so ne Idee ganz kurz verfolgen, ob das überhaupt wieso ne Machbarkeitsstudie absolut valide, da sagen wir auch nicht nee jetzt schreiben wir einen Test den wir zu 99% danach wieder löschen werden, weil wir gar nicht wissen was wir eigentlich gerade. Implementieren wollen, sondern
so ein bisschen ausprobieren. Da schreiben wir doch auch nicht
die Tests vorher. Also da würde ich auch sagen, ja, nee, musst du nicht machen und genauso diese Laws, die ich gerade beschrieben habe, das ist die Theorie, deswegen habe ich auch gleich gesagt, wer kennt es nicht und es fällt einem schwer, dass du trotzdem manchmal schon 23 Tests schreist, weil du im Kopf, das ist auch irgendwann eine erfahrungssache, dir denkst, ja, ich weiß doch, das muss ich machen, danach teste ich das ab, komm, wir schreiben mal schnell die 3 Tests runter,
die unsere Funktion. Gate abbilden und dann implementieren wir die 3 genau. Na also auch völlig OK. Na also sagen wir mal von der Theorie her ist es nicht OK, aber ich kann verstehen wenn das Leute machen ja nur man sollte sich dann halt immer wieder besinnen und sagen OK, jetzt aber nicht zu weit in die eine Richtung schon laufen sondern halt diesen Zyklus so gut es geht einzuhalten. Es ist ja meistens Trade Off zwischen Theorie und Praxis es.
Aber ratsam, ab und an vielleicht auch mal extra, sich hinzusetzen und zu sagen, jetzt mal kurz eine Stunde wirklich reinstes Ttd nach der Theorie und dann kann man ja auch mal wieder so ein bisschen mal davon abschweifen. Aber mal das erlebt zu haben, auch mal wirklich das ab und an mal wieder zu machen, ist auf jeden Fall ratsam. Aber wie gesagt, Print wie du schon sagst, so, es ist ja
einfach so, dass man auch. Im Daily Business halt einfach auch an der Stelle auch Erfahrungen, da auch ein bisschen mitbringen kann und sagen kann, komm ich weiß definitiv, ich habe ja jetzt schon im Kopf wie. Keine Ahnung, die nächsten 5 TDD Zyklen aussehen. Also come on. Ja, aber Fakt ist auch, es hilft ungemein, auch uns beiden in der Arbeit, im täglichen Doing und ich würde es auch nicht mehr umstellen. Das ist auch Real Talk, auch nicht privat.
Nee genau, also auch wenn wir jetzt zum Beispiel auf Twitch live coden, Liebe zuhören, liebe Zuhörer, falls du da noch nicht vorbeigeschaut hast, guck gerne mal zu, weil da arbeiten wir auch nach Tdd, dann kriegst du auch mal einen Eindruck von und. Glaube innerhalb der Community haben wir das auch schon ganz gut verbreiten können, dass Leute da auch Bock drauf bekommen und dass das natürlich auch ne sehr coole Sache.
Ansonsten würde ich sagen. Aus Cleancodesicht und Unittesting haben wir das ausführlich besprochen. Wir haben auch das First Prinzip erklärt, was ja so ein bisschen der Kern der Folge war. Daumen geht hoch und vor allem sehr gut. Und deswegen würde ich sagen, beenden wir hier diese Folge und auch dieses Kapitel in unserer Cleancode Reihe. Liebe.
Zuhören, liebe Zuhörer, falls ihr die Folge gefallen hat oder du Anmerkungen dazu hast, dann schreib uns gerne, zum Beispiel über die Podcast Mail, den die Mail findest du in den Shownotes auch gerne allgemeines Feedback zum Podcast. Was dir gut gefällt, was verbesserungswürdig ist. Wir sind da auf jeden Fall auf deine Mithilfe angewiesen und freuen uns über jede einzelne Nachricht. Und natürlich, wenn dir der Podcast gefällt, dann bewerte ihn doch gerne bei dem Provider deiner Wahl.
Das wird uns mega freuen oder empfehlen weiter an ein 2 Freunden. Das pusht uns ungemein in der Motivation, hier weiterzumachen und die anderen Plattformen wie zum Beispiel Twitch. Die Links findest du auch in den Shownotes und deshalb würde ich sagen, beenden wir jetzt diese Folge hier, wir hören uns alle beim nächsten Mal wieder und bis dahin eine gute Zeit. Ciao ciao deine Coding Bodys. Gemeinsam besser.