Latest / Coding Buddies | Tech & Dev-Mindset / Erstmal der Test Dude!

Transcript

Erstmal der Test Dude! · Coding Buddies | Tech & Dev-Mindset

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