Aber was ist denn jetzt, wenn du quasi Software in Spaceshuttle bringst und das funktioniert nicht so ganz? Und dann? Kommt jemand beim. Fallschirm an und sagte Alter, das hat überhaupt nicht funktioniert. Kannst du das vielleicht mal ein bisschen verbessern, so weißt du. Leider nochmal. Diesmal klappt Coding Buddy, Dein Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Ein herzliches Hallo und schön, dass du wieder eingeschaltet
hast. Hier beim Coding Bodies Podcast zur neuen Folge. Und ja, deine beiden Gastgeber sind wieder dabei, nämlich ich, der Fabi und natürlich der wunderbare Tino Tino. Hi Hi, Grüß dich. Na, wie geht es dir im schönen, verregneten Sommer? Ja gut, was willst du machen? Also für mich ändert sich ja nicht viel, ich sitz drin am Computer. Ja, wir nehmen einen Podcast auf, Scheiß drauf, draußen regnet und dann ist. Gut auf. Was wollen wir denn heute mal so n bisschen thematisieren?
Ja, du hattest ja vorgeschlagen, dass wir in der Folge übers Test machen und das geiles Thema, Ja, geiles Thema, Super geiles Thema. Nein, das wollen wir natürlich jetzt hier an der Stelle auch mal machen, aber nicht im Allgemeinen ums Testen von Software, sondern speziell um TDD, also t. Development, Du hattest ja auch schon erwähnt, dass da auch schon jahrelang quasi nach diesem Modell arbeitest und nach dieser Methode.
Ja, und deswegen wollen wir das heute ein bisschen vorstellen, n bisschen vor und Nachteile quasi beleuchten und ja unsere Meinung einfach mal dazu abgeben, ne und deswegen würde ich sagen, du als Verfechter stell doch mal bitte die Methode noch mal ganz kurz und knackig vor, damit jeder weiß, worum es hier eigentlich geht und ja und dann fangen wir einfach mal darüber n bisschen zu quatschen. Genau, also erstmal grob ganz
grob. Test Driven Development bedeutet im Ja ganz groben, dass man erst einen Test schreibt und dann wirklich die Implementierung des eigentlichen Codes macht. Die TDD hat 3 fasen oder 3 Stufen und zwar einmal das Testen, das ist die erste Stufe, dann die Implementierung und dann sozusagen das Recht, das ist auch eine dritte, also ne die dritte Phase sag ich mal des TDS. Die manchmal auch vergessen wird und die auf jeden Fall sehr
wichtig ist. Das heißt im Endeffekt erst testen, dann implementieren, defekt dann oder manchmal heißt es auch einfach Red Green Refecto, das heißt, der Test ist rot, danach implementierst du die Funktionalität, der Test ist grün und danach recht, dass du nochmal und versucht die Qualität zu erhöhen, ohne dass du eben genau den die Funktionalität veränderst. Ja, so viel da.
Genau. Genau rot und grün quasi nach dem Ampel Modell. Ne, also wenn der Test rot läuft, dann ist er quasi fehlgeschlagen, dann ist die Nationalität nicht so erfüllt worden oder umgesetzt worden, wie man das quasi erwartet in seinem Test. Genau. Nochmal kurz zur Erläuterung. Zum Beispiel die Implementierung halt nicht da ist so als allererstes also das. Sollte ja im Prinzip immer das Verhalten am Anfang sein, oder? Genau. Und ich mach das jetzt auch schon wie du meintest.
So seit über 5 Jahren arbeite ich nach TDD und hab halt einfach mitgekriegt. Das ist wirklich eine gute Sache, ist. Also tatsächlich war es bei mir auch so, dass ich ja ganz am Anfang und nach der Uni gar
keine Ahnung davon hatte. Also ich hab mit testen gar nichts am Hut gehabt, nur mal um so ein bisschen das ganze Mal kurz aufzurollen, dass man sich vorstellen kann und dann hab ich ja so den Job in der Abteilung, wo ich jetzt vorher, bevor ich zu dir in deinem Team gewechselt bin, gearbeitet hab, da bin ich hingekommen und hatte auch, ich wusste also, ich habe vorher noch nie t gemacht, aber da. Wurde halt t praktiziert. In der kompletten Abteilung und. Ja, das ist halt immer.
Es ist auf jeden Fall ne Umstellung, ne, also das ist jetzt mal was man so n bisschen vorwegnehmen kann um einfach mal zu sagen OKTDD ich bin davon überzeugt, man muss aber auch wirklich sagen man muss da ein bisschen umdenken, ne. Also selbst als ich damals angefangen hab hab ich mir auch gedacht K wie geht denn jetzt die Implementierung? Ich würd ja mal gerne schon mal implementieren, ne, dass du halt
so ein bisschen erstmal. Also das ist es ist halt eine Umstellung, weißt du der von der Art und Weise wie du
programmierst? Na ja, gut, ich glaube, das kennt eigentlich jeder ne. Also du überlegst dir ein feature, du sagst ja, meine Software soll jetzt quasi das und das noch können und dann öffnest du den Source Code und willst am liebsten sofort anfangen zu Coden, schreibst neue Funktionen whatever aber das ist ja genau der Weg den man dann nicht gehen soll, sondern sich wirklich erst mal, sagen wir ruhig in Ruhe überlegen soll, was möchte ich denn
eigentlich umsetzen? Genau und dafür schreibe ich ja den Test. Also ich überlege mir quasi. Wie genau soll das Verhalten meiner Software sein? Schreibt den Test und muss dann ja sehen, dass meine Software
das noch. Nicht tut genau, vielleicht ist es auch mehrere Tests für ein Verhalten, also nach und nach ne, dass man sozusagen sag ich mal die im Endeffekt ist es ja was das was da passiert ist ja im Endeffekt, dass man sag ich mal auf der Gewissen in Ebene, die man in dem man den Test schreibt, weil es auf verschiedene Test Ebenen gibt, können wir auch nochmal drauf eingehen und das ist ja im Endeffekt du legst die Spezifikationen fest.
Was soll dieser dieses Modul, dieses Teil, diese Funktion, was auch immer, was soll die machen, ne, und wie soll sie sich verhalten? Also das ist genau der Punkt, den man im Vorfeld festlegt und bei mir war es zum Beispiel auch so, dass. Ich quasi.
Nur mal um das bei falls zum Beispiel der Zuhörer oder die Zuhörerinnen sich überlegt, OK, ich möchte jetzt development machen und mal anfängt damit ne, weil wir das ja auch beide, du kennst das ja auch, du machst das jetzt mittlerweile auch und wir können ja beide empfehlen nur, dass man sich vorstellen kann, dass man durchaus dahin kommt und sagt, ich probier das jetzt mal und aber das Gefühl hat OK.
Ist irgendwie doof, dass das funktioniert nicht und es ging mir auch so. Also ich hab angefangen, dass ich mir dachte, OK es du, du bist in der Lage, dass du irgendwann in die Arbeitswelt gehst.
Du arbeitest du, du hast das Gefühl, OK, ich kann das und jetzt kommt wieder das nächste Ding, dass du dir denkst, scheiße, jetzt muss ich wieder umdenken, weil ich hab doch jetzt verstanden, wie sozusagen so algorithmisches denken funktioniert und jetzt muss ich auch anfangen, erst mal darüber nachzudenken, wie ich den Scheiß teste. Weißt du also das ist so ne kleine Umstellung, die man dann wieder hat und da wollte ich nur einmal. Ganz kurz sozusagen vorwegnehmen, wenn man damit
anfängt. Es ist erstmal wie bei vielen Dingen ja am Anfang auch erstmal ein bisschen kompliziert, n bisschen verwirrend vielleicht, oder man muss umdenken, ne, das würde ich sagen, oder? Was auch ein ganz wichtiger Punkt dabei oder beziehungsweise ein Argument, was oft auch gegen TDD gebracht wird. Man hat halt schon das Gefühl, gerade am Anfang, wenn man anfängt mit dieser Methode zu arbeiten, so ein bisschen ausgebremst zu werden, ne, also wir haben ja auch über Programming.
Gesprochen, und da hatten wir beide ja jetzt, wenn wir zusammen entwickelt haben, ja oft die Situation, dass wir uns überlegt haben, Features umgesetzt werden soll und ich hab halt einfach los gekostet in alter Tradition und du sagst dann quasi neben mir, auch wenn remote war, aber ich habe. Richtig gespürt. So Na na na na na, erst den Test schreiben, weißt du und denkst, oh nein, ich will doch imitieren, aber dieses Gefühl von ausgebremst werden, weißt du was ich meine? Ja, das.
Ist das ist witzig, weil genau also genau das gleiche Verhalten
hatte. Nicht sozusagen vor, ich sag jetzt mal Robot, 5 Jahren eben auch da saß ich auch da und dachte mir, Oh, jetzt geht's los, ich programmiere n bisschen was ne und immer wieder so mein perring Partner, wir müssen erstmal den Test schreiben so und das muss ich erst mal einbrechen und das ist teilweise schwierig und anstrengend, man denkt sich jetzt hör doch mal auf mit dem Quatsch so ne bis ich wirklich mal einen hatte der dann auch meinte Ja kommen wir
implementieren das erstmal so und dann hat sich irgendwann Perry Partner der meinte Wir sind die Tests aha na dann löschen wir das einfach alles und fang nochmal von vorne an ich dacht mir so. Okay das ist krass, das ist
krass. Ist aber auch nicht unbedingt die feine Art, weil im Endeffekt ist es ja trotzdem irgendwie gerade wenn du ein Wirtschaftsunternehmen arbeitest, so, dann ist es halt auch wieder die Frage so, also jetzt irgendwie komplett Arbeit wegschmeißen ist auch nicht das gute, aber an der Stelle war es halt wirklich, dass die Qualität an oberster Stelle stand und TDD natürlich auch ein bisschen, gerade weil wir eben schon gesagt haben, spezifiziert im
Vorfeld, was passieren soll und danach kann man das implementieren. Das ist sozusagen ja diese dieser Qualitäts Punkt, den man dann hat. Das ist ja auch ein Unterschied zu du schreibst erst die Implementierung und den Test. Weißt du, kannst ja also testen geht auf verschiedene Art und weisen, TD ist ja nur eine Art und Weise wie man das machen kann. Man kann natürlich auch hinterher testen, aber das hat
auch seine Nachteile, ne? Also was mir aufgefallen ist, das ist natürlich auch jetzt vielleicht ein bisschen weitläufig, aber ich würde es gerne mal kurz anschneiden, wofür TD super geeignet ist. Gerade dadurch, dass du dir im Vorfeld überlegst, was die Funktion machen soll. Ja. Beziehungsweise sind nicht mal die Funktion. Sagen wir einfach die Software allgemein irgendeine Komponente danach Software, dann versuchst du das ja abzubilden in dem Test.
Also das Verhalten zu reproduzieren und willst dann dein Ergebnis sehen, wenn es noch keine Implementierung gibt dazu hast kommst du auch nicht in die Versuchung deine Implementierung zu testen, was ich damit meine ist einfach du schreibst nicht den Test angepasst auf deine Implementierung und hast am Ende eigentlich gar nicht getestet, weil das ist auch so. Ne, so ein Rabbit hole wo man ganz schnell reinkommt, heißt der.
Punkt. Ja, das ist auf jeden Fall genau, das ist ja sozusagen ja, wie du gerade gesagt hast, das perfektes Beispiel, und das ist genau das, was TDDH im Vorfeld sozusagen vermeidet. Ne, also angenommen du hast bereits n Fehler einprogrammiert und testet dann den Test. Dann Test du vielleicht sozusagen so, dass der Test grün läuft mit diesem Fehler ne und damit hast du sozusagen neben einer genauen Spezifikationen ja auch sogar noch ne frühere Fehlererkennung, die du halt sozusagen.
Als vorteilhaft durch TDD, das ist auf jeden Fall ein wichtiger Punkt zusätzlich, was auch ne Sache ist.
Was mir also, weshalb ich zum Beispiel, das ist für mich ein sehr, sehr großer Punkt, der mich auf jeden Fall zu einem absoluten Tester und TD Verfechter gemacht hat mittlerweile ist, dass ich irgendwann mal an den Punkt kam, dass ich mir, also da haben wir, weißt du, wir machen ja auch manchmal privat so ein paar Sachen Code n bisschen rum und so und da haben kann ich mich noch erinnern, Spring Boot Anwendungen geschrieben und haben gesagt die Reflektoren
jetzt mal durch. Einfach dadurch, dass wir quasi auch früher, wir haben ja mitbringt beide angefangen n bisschen rumprobiert und wurden dann besser und haben uns dann gesagt, wir verbessern das jetzt dann nochmal mit neuem Wissen. Ne was halt einfach immer wieder. Also da muss man immer ne, also können wir nochmal drüber reden irgendwann in einer anderen Folge, aber das ist halt ein wichtiger Punkt, weil genau dieses Referat und wir hatten zu diesem Zeitpunkt keine Tests und.
Ja, stimmt stimmt und da. Wusste ich oder was was wo ich halt. Ich hab dann gemerkt habe. Scheiße bin ich das jetzt reflektiere. Keine Ahnung ob das hinterher noch funktioniert oder nicht und dieses Vertrauen, was TDD, was diese Tests ne also gut normale Tests tun das vielleicht auch, aber wir haben ja gerade gesagt, was der Vorteil von TDD gegenüber von erstmal implementieren testen ist was das schafft einfach vertrauen,
dass man weiß OK ich. Verändere jetzt was ich verändere, sozusagen die Qualität, aber nicht die Funktionalität. Und die Tests sind dafür da, dir zu sagen, OK, es funktioniert immer noch alles so wie vorher, ne. Na ja gut, das ist natürlich ein Argument, was allgemein für das testen auch spricht. Ne definitiv nicht nur jetzt fürs TDD, aber wie ich halt auf jeden Fall der große, also wirklich einer der großen Punkte
ist, warum man einfach testen. Sollte genau deswegen genau das macht halt einfach eben dieses Vertrauen hat, dass man weiß, OK, wenn ich jetzt was verändere, dann mach ich jetzt nicht die ganze Software kaputt und das ist wichtig. Also das ist für mich auf jeden Fall ein sehr wichtiger Punkt, der sehr, sehr schwerwiegend ist. Wieso ich zum Beispiel auch immer auch teilweise Nerven und sage, wir müssen das irgendwie testen.
Nee, ist richtig, das ist richtig, ist ja auch wirklich, wirklich wichtig, da hätte ich auch noch einen anderen Punkt, und zwar weil du meinst, testen ist wichtig und die Tests und schaffen vertrauen. Wie siehst du das? In meinen Augen ist die Qualität der Tests also auch wie die geschrieben sind. Eigentlich gleichwertig mit der mit der mit dem Source Code, also dem Code der eigentlichen Software. Also ich finde das auch, zum Beispiel Tests reflected werden müssen.
Ja ich stehst du dazu definitiv. Also das ist natürlich also ne, es kann durchaus sein, also fangen wir mal dabei an erstmal die Quali, weil du gerade von Qualität der Tests gesprochen hast. Ne. Wichtig ist zum Beispiel hatten wir glaube ich irgendwann mal erzählt oder irgendwann mal gesagt im Podcast, dass es wichtig ist, wie die Tests benannt sind. Also ist es wichtig, dass du den Test Namen gibst, die wirklich ausschlaggebend zu dem sind, was sie wirklich abtesten, damit man
auch wirklich weiß, was los ist. Das ist zum Beispiel auch so ein Punkt, der einem dabei hilft. Das ist eine gewisse Art von Dokumentation, ist ne, wenn es denn wirklich gut gemacht ist. Und zusätzlich sollte natürlich auch ein Test, wenn du dir diese Tests anguckst und eben diese Dokumentation sag ich jetzt mal, liest ne in Anführungsstrichen, dann musst du natürlich auch irgendwie dich da durch finden und deswegen sollte natürlich auch der Code des Tests so sein, dass man eben das auch
einigermaßen gut. Versteht. Also ich hab auch schon durchaus Momente gehabt, wo ich erstmal
den Test verstehen musste. Also ich hab mir den Namen durchgelesen, soweit so gut, dann kommt der sag ich mal die Implementierung der Code des Tests ne so also wie wurde der Test geschrieben und dann erstmal zu gucken OK was passiert denn hier eigentlich ne irgendwelchen Elementen rumgeklickt oder irgendwelche Sachen sag ich mal irgendwelche Daten aufbereitet die man dann vielleicht für den Test braucht wo man dann erstmal was passiert da genau ich weiß was dieser
Test sagt aber. Ich ne, was ist da los? Was für ein Verhalten wird eigentlich getestet? Ja. Genau also, dass man vielleicht auch so OK, man kann ja durchaus auch sagen, weiß ich Test 123 hat den gleichen Aufbau am Anfang, dann hat man irgendeine initialisierungs Funktion, die sagt EY initialisieren Test. Das muss eigentlich für jeden Test, für diesen, für diese Komponente gemacht werden und dann weiß man halt, OK, das muss ich mir nicht angucken, da steht das wird initialisiert, fertig
und jetzt gehts los. Irgendwie solche Sachen genauso wie man zum Beispiel. Meiner Meinung nach auch sagen kann zum Beispiel dieser Test. Der ist also, dass man sich regelmäßig auch mal anguckt. Ist dieser Test noch valide, weil es bringt ja nichts, wenn du 100 Tests hast und 90 davon sind alle alle laufen grün und 90 davon, sagen aber gar nichts
aus. Ne, genau dass man auch wirklich mal sagen kann, OK, ich kanntest auch weg löschen weil es bringt ja nichts wenn du ein Test hast der im Endeffekt und also dir nichts sagt dir keinen Mehrwert. Gibt genau, und da sind wir auch wieder beim Refactor. Du kannst ja auch mal Test zusammenlegen, weil du merkst, ja, gut, irgendwie muss ich das
nicht. Trend testen das irgendwie dann doch ein und dasselbe am Ende ja oder halt zum Beispiel auch den Code aufräumen, wie du meintest, dass man sagt Okay Pass auf, ich mach das jetzt gefühlt in jedem Test. Jetzt schreibe initialisierungs Funktion dafür beispielsweise oder was bei uns oder zum Beispiel auch klassisch ist.
Denn einfach zum Beispiel so ein Test Data Bilder schreiben, dass du einfach ein quasi ein generellen Punkt hast, wo du einfach so Testdaten generieren kannst, damit du nicht jedes Mal Fängst wieder irgendwelche Testdaten zu überlegen. Beispielhaft also, dass das räumt ja auch die Test ungemein
auf, dann. Ja, am Ende ist es halt auch wieder so ein bisschen so. Muss halt n bisschen abbiegen, weil ich hab glaub ich hab auch schon mal erlebt, dass ein Test Data Bilder komplett ausgeufert ist und man sich einfach nur dachte, Oh mein Gott, was ist das für ein Monströsität wolltest irgendwas ist echt, du wolltest irgendwas ändern und dachtest du Scheiße, das kann ich so nicht machen, weil dann gehen irgendwie andere Tests kaputt und die Daten werden
nicht mehr richtig ist natürlich n 2. Ist natürlich genau das muss natürlich auch das Kleinste gehalten werden, aber es ist halt einfach kein schlechter Ansatz, wenn man merkt, ich brauche das halt immer wieder irgendwie ne. Absolut, ja, definitiv genau.
Und außerdem so gängige Test Frameworks stellen, die natürlich auch gewisse Funktionalitäten bereit, wo du halt zum Beispiel so Before each Funktionen implementieren kannst, sie quasi vor jedem Test laufen und so, dann wird ja auch viel an die Hand gegeben um Struktur reinzubringen. Ja. Das auf jeden Fall. Wie gesagt, man muss natürlich auf der anderen Seite sagen, was du auch schon mal jetzt im am Beginn der Folge glaube ich angemerkt hast, dass es natürlich eine Zeit intensive
Entwicklung ist. Ne, also es ist manchmal auch so, also wenn man jetzt sagt, OK, man arbeitet nach TD ist ne gute Sache, kann ich nur unterstützen, also wenn da draußen liegt wer sich überlegt OK mach ich das. Wir sagen auf. Jeden Fall mach, das ist eine gute Sache. Man sollte aber auch wiederum
gucken. Dass, wenn du jetzt zum Beispiel die hinstellt und sagt, Ey weiß nicht, ich weiß noch gar nicht, wie ich an die Sache rangehen soll, ne, also du hast vielleicht irgendwie ne Art und Weise sozusagen, funktioniert das überhaupt, was ich mir jetzt gerade vorgestellt hab, ne, dann ist es natürlich auch durchaus mal so, dass man sagen kann, OK, lass uns erstmal einen Prototyp entwickeln, ne um zu gucken, funktioniert das überhaupt, was wir uns gerade überlegt haben,
weil ich sag mal so ne, also Test Driven development ist natürlich eine langsamere Art und Weise den Code zu entwickeln natürlich, aber. Wie auch beim Programming. Du vermeidest Fehler im Vorfeld und diese Fehler Erkennung, Fehler Findungen und Fehler korrigieren. Der Fehler ist dauert meistens noch viel länger, das heißt im Vorfeld investiert man schon sozusagen jetzt in die Zukunft, aber das wird natürlich auch nicht immer gesehen, sondern am
Anfang selbst. Für einen selber fühlt sich das natürlich so an. Ey, da geht ein bisschen langsamer voran und wenn man jetzt aber nicht weiß i wie funktioniert das was ich mir überlegt hab, dann ist es durchaus meiner Meinung nach. Du kannst ja auch mal sagen wie du dazu stehst. Es ist meiner Meinung nach durchaus valide zu sagen, OK, ich versuche jetzt erstmal, sozusagen funktioniert das ein Prototyp ungetestet, bis man denkt, dass man sagt es funktioniert nicht.
Ne gut, dass ich es nicht getestet hab oder? Ja genau so funktioniert es jetzt kann man quasi wirklich nochmal starten mit mit TD. Beispiel Ja.
Das ist ein spannender Punkte. Im Prinzip hätte ich dich jetzt auch gleich noch gerne das was ähnliches gefragt, weil wenn man also wenn man jetzt wirklich mal überlegt wofür man TD einsetzen kann, ist das jetzt nur für etwas was produktiv geht, also für meinetwegen eine Softwarelösung, die halt auch wirtschaftlich sein soll oder nutzt man TDD auch für kleine Tools, die man privat entwickelt nur für sich ja oder zum Beispiel? Hat mir auch das Thema MWP.
Nutzt man es dafür oder sagt man ja, nee, da will ich einfach nur sehen, dass es geht ne spannende Frage, ich bin mittlerweile an dem Punkt, dass ich mir denke, ich mag so sehr die Zuversicht oder dieses Vertrauen in meine Software, die ich durch diese Tests bekomme, also das Vertrauen was ich dadurch bekomme, dass ich eigentlich. Kein Fall. Jetzt weiß, wo ich es nicht machen würde, also zumindestens
immer Test schreiben. Klar wie gesagt, man neigt auch mal dazu mal schnell anfangen anzufangen, zu implementieren und dann verdammt OK jetzt schnell noch den Test schreiben, das passiert immer mal ne also da muss man wirklich los, du musst halt da verdammt diszipliniert sein und das kann halt auch mal sein, dass du erst implementierst. Aber grundsätzlich testen immer ja TDD.
Eigentlich auch immer. Warum nicht also für mich spricht nichts dagegen, ich hab halt auch nicht das Gefühl, dass ich auf die gesamte Entwicklungszeit langsamer werde. Klar, es fühlt sich am Anfang manchmal wie eine Handbremse an. Weil man einfach halt quasi ja, also 2 verschiedene Code Elemente hat. Einmal die den Code vom Test und einmal von deiner Software an sich, den du verwalten musst, den du refactor musst.
Das ist auf jeden Fall Mehraufwand am Anfang, aber hinten raus, also selbst dein privates Tool soll doch am Ende funktionieren, oder? Und selbst da wirst du Reflektoren oder Sachen ändern und dann weißt du nicht mehr wo vorne und hinten ist. Wenn du dazu keine Tests hast.
Ja, ja, also. Ich, ich weiß was du meinst und ich finde auch, dass man auch selbst, also wenn ich irgendwen irgendwie privat was entwickelt, irgendwelche Tests hab ich auf jeden Fall immer am Start, auch wenn man jetzt zum Beispiel sagt, OK, MAN entwickelt wirklich ein Produkt für irgendeinen Kunden, dann ist es natürlich durchaus definitiv eigentlich unvermeidlich meiner Meinung nach, dass man Tests hat, aber wenn man sich jetzt auch eigene Tools schreibt, die
man vielleicht auch im beruflichen Umfeld benutzt, es ist ja nur sinnvoll zu sagen, OK, funktionieren die auch so, wie ich mir das vorstelle, ne, also da an der Stelle Tests zu benutzen. Auf jeden Fall auch sehr von Vorteil. Definitiv ne.
Würde ich auf jeden Fall auch unterstützen, was natürlich durchaus vielleicht eine Möglichkeit ist, dass man also ne, wenn es kommt, immer ein bisschen darauf an, welche Software hat man denn gerade, an welcher Software arbeitet man gerade ne und es ist natürlich auch die Frage oder es gibt manchmal so berechtigte, würde ich vielleicht sogar sagen, berechtigte Ausrufe, dass man sagt OKTDD, wenn du sagst, OK, du machst entwickelt ein Produkt wirklich nur nach TDD, das im
Endeffekt sozusagen die Qualität, die dieses T also TD soll ja quasi diese Qualitätssicherung. Irgendwo ein bisschen auf einer gewissen Art und Weise bieten. Ne ne, dass du sagst, OK ist es denn also der Entwickler die Entwicklerin selber soll sich ja quasi um die Qualität des Codes kümmern, was natürlich richtig ist.
Und es gibt durchaus manche die sagen ja gut TDD, dann wird das getestet, du hast ne Test Automatisierung, das heißt die Tests laufen bevor irgendwie n neuer Stand deployed wird ne von von von dem Produkt und dann war es das auch so, dass halt eben. Quasi weg kommt von diesem. Es wird auch noch mal extern getestet, beispielsweise ne und da.
Bin ich auf jeden Fall auch auf der Seite so OK, solche Zyklen zu vermeiden zu sagen hier ich hab einen neuen Stand bitte externe Tester Teams, bitte checkt das auch noch mal, dann wird das durchgecheckt, dann dauert das eine Woche, dann kommt das irgendwann wieder zu dir zurück und du selber denkst dann boah ja OK jetzt hab ich wieder die und die Sachen, vielleicht kannst du in der Zeit nicht entwickeln weil ihnen abgenommen werden muss oder was auch immer das heißt du hast
Riesen lange Zyklen bis du quasi wieder Code weiterentwickeln kannst und deswegen würde ich halt zum Beispiel sagen OK. Macht Sinn zu sagen, lasst doch diese externen Tester weg, kümmer dich als Entwickler nur darum, dass du deinen Code sozusagen abgestellt und dann ist es gut. Da kommt natürlich ein bisschen ins Spiel.
Was ist denn jetzt ne, wenn du jetzt irgendeine Anwendung hast, du Internet benutzt wird und feiern irgendeine Eingabe funktioniert nicht so richtig, dann ist das eine Sache, die es vertretbar. Aber was ist denn jetzt, wenn du quasi Software in Space hatte bringst und das funktioniert nicht so ganz? Und dann? Kommt jemand beim. Fallschirm an und sagt Alter, das hat überhaupt nicht funktioniert. Kannst du das vielleicht mal ein bisschen verbessern, so weißt du. Leider nochmal.
Diesmal klappt. Also das ist natürlich, und da ist es berechtigt, vielleicht zu sagen, OK, man muss vielleicht gucken, für welches Produkt, für welchen, für welchen Anwendungsfall. Wird wie was getestet, also weißt du ja, ich weiß was du meinst. Das Ding ist, wenn dein deine Software Sicherheits kritische Anforderungen hat. Kleine Exkurs bei uns auf der Arbeit entwickeln wir ja grundlegend auch Software, die
Sicherheitskritisch ist. Und natürlich ist das was anderes, wenn du einfach irgendeine Web Oberfläche machst und keine Ahnung da ist ne falsche Farbe drin, weil jetzt nicht so gedacht das ist juckt niemand, vielleicht rein optisch, aber da wird niemand verletzt, ne? Was du aber bei Sicherheits kritischer Software hast, sind natürlich Prozesse, die du einhalten musst in der Entwicklung. Und diese Prozesse sorgen am Ende dafür, dass du diese Gewährleistung und Freigaben
bekommst. Und damit meine ich jetzt nicht nur das testen. Klar testen ist ein Punkt davon, aber du hast natürlich dann auch zum Beispiel Vorgaben wie Review wird. Na also das ist richtige Review Protokolle gibt und je mehr. Prozesse du da drauf packst, nehmen wir zum Beispiel per Programming, haben wir auch
darüber gesprochen. Das ist ja so ein unmittelbares Review, was gleichzeitig zur Entwicklung stattfindet, was ja auch die Code Qualität steigert, dazu die Tests, dann hast du immer mehr Sicherheit, dann kommst du irgendwann an den Punkt, dass noch mal externe Leute das Review ne und freigeben, dann kommen halt noch Gesamtsystem Tests beispielsweise also du du gehst ja immer mehr weg von Deiner Software hin, vielleicht zum gesamt Produkt.
Oder guckst halt immer mehr von außen drauf und du steigerst ja immer mehr die Zuversicht, dass es läuft. Also was ich meine ist, je sicherheitskritischer das ist, umso mehr Auflagen, Prozesse musst du einhalten für diese Freigaben. Ja, ja, genau, ja.
Also das ist auf jeden Fall ein Punkt und da kann ich mir durchaus vorstellen, dass es vielleicht unter bestimmten Umständen und Sicherheitsaspekten vielleicht durchaus wichtig ist, an der einen oder anderen Stelle zu sagen, ey. Du kannst nicht einfach nur den Entwickler oder die Entwicklerin, die Software Qualität sichern lassen, ne, aber ich denke es.
Also ja, es kommt halt einfach drauf an ne also weil ich das auf jeden Fall schon mal erlebt habe, dass es den einen oder anderen Hinweis auf jeden Fall schon mal oder die Diskussion, die ich schon mal erlebt habe, dass es dann hieß. Ja, aber. Du kannst doch nicht einfach nur den Code und die Tests von der entwickelnden Personen quasi aus also ausführen lassen. Sozusagen also beziehungsweise entwickeln lassen. Und. Das sehe ich halt wie gesagt ja und.
Nein, also das ist für mich so ein Punkt, wo ich sage, es kommt drauf an. Aber im Normalfall, wenn wenn es wirklich nicht, also wenn es nicht so kritisch ist, dann würde ich sagen, lass diese ganzen Feedback Zyklen weg, die irgendwie Zeit sag ich jetzt mal in der Entwicklung verlangsamen, sondern versucht möglichst effizient da eine Software sag ich jetzt mal zu gestalten zu. Also die, die das Vertrauen in
die Software zu gewährleisten. Und das geht meiner Meinung nach ziemlich gut eben mit TD ne einfach aus dem Grund, du hast ne frühe Fehler Erkennung, ne Spezifikation, ne Dokumentation, das Vertrauen über den Code und wenn es darüber hinaus geht, klar kann man darüber reden, aber ich finde das ist auf jeden Fall schon mal. Ein sehr wichtiger Punkt, der das Ganze irgendwie. Ausmacht. Ja ja seh ich auch so. Wie gesagt. Je also alles, was dann noch on top kommt.
OK, aber du kannst eigentlich immer nach TD arbeiten, egal was für ein Projekt du bist, wie egal wie Sicherheitskritisch das Ganze ist ne genau ja ich würde sagen lass uns die Folge hier beenden, das hat jeder Spaß gemacht darüber zu reden und beim reden hab ich halt auch gemerkt, dass es, dass es einen Grund gibt, warum wir danach arbeiten. Ich feier das total ab danach zu entwickeln und.
Danke fürs Jahr nicht. Bitte, bitte und liebe Zuhörerinnen. Hör auf hier die Folge gefallen hat, lasst doch gerne ein Like da. Meld dich auch gerne auf den anderen Plattformen. Die Links findest du in den Show Notes. Uns würde auf jeden Fall interessieren, wie du die Folge fandst wie du zu TD stehst, ob du vielleicht Lust das mal auszuprobieren oder vielleicht schon jahrelang danach. Arbeitest damit. An meld dich ja und ansonsten damit an. Genau.
Meldet euch und ansonsten würde ich sagen, vielen Dank, habt noch einen schönen Tag und bis zum nächsten Mal eure Coding Bodys gemeinsam. Besser.