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.