Latest / Coding Buddies | Tech & Dev-Mindset / Clean Code #8 - Testing F.I.R.S.T.

Transcript

Clean Code #8 - Testing F.I.R.S.T. · Coding Buddies | Tech & Dev-Mindset

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