Latest / Coding Buddies | Tech & Dev-Mindset / #132 Lösch endlich deine Tests!

Transcript

#132 Lösch endlich deine Tests! · Coding Buddies | Tech & Dev-Mindset

0:00
Wenn du Tests hast, ja, und jemand sagt ja, dann lösch die
0:02
Tests, dann war mal so. Hahaha ich bringe dich um Coding
0:06
Buddies dein Podcast rund. Um Softwareentwicklung und
0:09
aktueller Tech News. Herzlich Willkommen
0:23
einen wunderschönen guten Tag und herzlich Willkommen zur
0:27
neuen Folge vom Coding Buddies Podcast.
0:31
Ja, was auch sonst? Und zwar mit mir, dem Fabi und
0:35
dem fantastischen Tino. Denn Tino, ich find dich auch
0:37
fantastisch, ich weiß, du sagst immer zu mir fantastischer Fabi,
0:40
aber ich find dich natürlich auch fantastisch und deswegen.
0:42
Dankeschön. Dankeschön.
0:43
Wie geht es dir? Ja Moin fabi, mir geht es gut,
0:47
ich hab Bock, ich bin bereit, das ist soweit ne neue Folge, es
0:52
geht los ja neue Woche neues Glück ja genau so.
0:58
Nee, mir geht es gut, ich bin fit, wir sind ja quasi jetzt ins
1:03
letzte Quartal des Jahres gestartet und schon wieder ne
1:07
mal gucken, was es noch so. Bereithält, war ja quasi gerade
1:11
erst Neujahr und so weiter und Frühlingsanfang ne, jetzt ist
1:15
schon wieder, es geht ja mal schnell ne ist ja mal.
1:17
Wir haben über den Sommer gesprochen, dass da mal viel los
1:20
ist und jetzt ist auch schon wieder ja hör auf und jetzt
1:22
kommt die Zeit wo es wieder richtig schön.
1:26
Nicht so viel los ist, obwohl doch wieder wahrscheinlich viel
1:29
los ist. Ja, es wird wieder n bisschen
1:31
kälter, n bisschen ungemütlich das er wird uns ja jetzt alles
1:35
wieder zu erwarten, aber eine Sache die vor der Tür steht und
1:40
die richtig ein Lächeln ins Gesicht zaubert, ist natürlich
1:44
unser nächstes Turnier fabi. Ja, auf jeden Fall.
1:47
Der nächste Programmierturnierwettbewerb
1:50
steht in den Startlöchern, auf jeden Fall ganz genau, wie
1:54
gesagt. Stellt euch alle schon mal drauf
1:56
ein, da gibt es wieder was zu gewinnen und es gibt auf jeden
1:59
Fall wieder ne richtig coole Turnier Action auf Twitch.
2:03
Dann am Ende und die Infos gibt es natürlich alle noch ne, also
2:07
da folgen auf jeden Fall Infos noch auf unserer Website, auf
2:10
Social Media ne, also jetzt nicht gleich völlig eskalieren
2:13
und sagen ich weiß auch gar nichts, ja noch gibt es noch
2:17
nicht so viel zu wissen, aber es gibt natürlich immer mehr Infos,
2:21
auf jeden Fall ne, also seid auf jeden Fall gespannt und bereit.
2:24
Genau die Infos haben wir dann auf unsere Website und werden es
2:27
natürlich über Social Media auch verbreiten.
2:29
Aber ich sag mal so es es es steht sehr sehr nah vor der Tür.
2:35
Ich bin schon richtig aufgeregt, ich dachte es steht sehr viel
2:37
auf dem Spiel, dachte sowieso geht um Ruhm und Ehre.
2:45
Genau. Und natürlich Vergesst auch
2:48
nicht, unserem Podcast zu folgen, weil wir werden ja auch
2:50
im Podcast die nächsten Wochen über dieses Turnier sprechen.
2:53
Das heißt, folgt diesem Podcast, verpasst keine Folge, aktiviert
2:56
auch gerne das Glöckchen und ich denke, das sind so die, die
3:01
vorweg Sachen ja, bevor wir jetzt zum Thema kommen, die
3:03
haben wir jetzt mal abgehackt so Check und du hast n cooles Thema
3:08
mitgebracht, du hattest mir n. Artikel geschickt und dann
3:12
hatten wir mal so n bisschen drüber gebrainstormt, weil wir
3:15
den Inhalt ganz cool fanden, den könnten wir ja auch mal
3:16
verlinken. Aber erzähl doch mal.
3:19
Worüber möchtest du heute sprechen?
3:22
Genau, also es geht pass auf. Ja, jetzt denkt man sich
3:25
vielleicht so, ha war ja klar ne testen, es geht irgendwie ums
3:30
Testen, aber wenn man das ganze jetzt noch mal so n bisschen
3:36
sich mal durch den Kopf gehen lässt ne also wenn man jetzt zum
3:38
Beispiel mal so. Es gibt ja so verschiedene
3:40
Aussagen, die man vielleicht so in Sachen testen hört.
3:44
Ja, also zum Beispiel sowas wie, also absolut richtige Sprüche
3:49
wie zum Beispiel ne schreib n neuen Test.
3:51
Wenn du ne Änderung machst, ne find ich erstmal an sich klasse,
3:55
ich weiß nicht wie siehst du das?
3:56
Also erstmal schreib n Test ist schon ne tolle Aussage schreib.
3:59
Test ist gut, schreib ne Test für Änderung noch besser so wenn
4:02
Bug auftritt ne erstmal mit einem Test den Bug
4:05
reproduzieren. Ne, dann fixen auch total geil.
4:10
Ne auch ne tolle Aussage kann ich auch unterstützen.
4:12
Ne es gibt natürlich auch sowas wie keine Ahnung, scheiß auf
4:15
Test schreibt keine Tests Tests. Schreibt, der ist nicht
4:19
überzeugt von seiner Arbeit und blablabla.
4:22
Das. Unterstützen wir dich?
4:23
Nein, aber ne, es gibt ja auf jeden Fall, aber was ist auf
4:26
jeden Fall was immer so ne Sache ist und das ich glaub das hab
4:29
ich auch relativ also sagen wir mal ne Zeit lang so.
4:32
War das für mich so n Credo zu sagen, Lösch halt keine Tests ne
4:36
also wenn du Tests hast ja und jemand sagt ja dann Lösch die
4:39
Tests, dann waren wir so hahaha ich bring dich um.
4:45
Ja, die waren immer so heilig. Ne, also so Testumgebung und
4:49
Tests sind heilig. Ne, du kannst ja auf gar keinen
4:51
Fall Test löschen und genau über diesen Punkt möchte ich auch
4:57
gerne sehr sag ich mal. Ja, ist spitz mit dir drüber
5:00
diskutieren, ne, also ist das wirklich so oder ist das Quatsch
5:04
und ich find das passt halt auch ganz gut rein.
5:06
Wir haben ja letzte Woche darüber gesprochen was sind so
5:08
Skills die wir nicht hatten während des Studiums?
5:12
Ne das war ja so ne Community frage was für Skills sollte man
5:17
sich neben dem Studium aneignen, die man dann so fürs
5:19
Arbeitsleben braucht und testen hatten wir da ja auch ganz groß
5:22
geschrieben und sind ja auch eine Woche später immer noch der
5:25
Meinung also es hat sich nicht geändert.
5:28
Und deswegen passt das gut rein. Aber man muss halt auch sagen,
5:31
Ja, testen ist nicht gleich testen und deswegen kommt dieses
5:33
Thema heute sehr gelegen, dass man auch mal noch mal so n
5:36
bisschen challenged. Was sind die richtigen Tests,
5:40
welche Tests bringen einem vielleicht nichts oder eher
5:44
können sogar Schaden anrichten. Ja, also man kann es ja auch so
5:47
weit treiben, dass man sagt, OK warte mal, das schadet meinem
5:50
Projekt jetzt eher als dass es hilft.
5:54
Und wenn wir da so n bisschen den Bogen spannen und dann noch
5:56
so n paar Learnings mitnehmen könnten für uns und für dich
5:59
liebe ZUE, liebe ZUE, wär das natürlich mega ne.
6:02
Absolut ja. Ich find es auf jeden Fall gut,
6:04
dass du noch mal angesprochen hast von der letzten Podcast
6:07
Folge mit den Tests, weil irgendwann bin ich zum Beispiel
6:11
dahin gekommen, dass so Tests quasi einfach gesetzt waren.
6:14
Ne so nach dir, also es war dann richtig so, das war so n
6:17
Jobwechsel ne bei mir und dann war so OK ab jetzt nur noch Test
6:19
driven development ne und dann hat sich tatsächlich auch.
6:23
Das war ganz krass. Hab ich mich da irgendwie, das
6:25
war ich sag mal so im ersten Monat ne, hab ich mich mit
6:27
jemandem dann zusammengesetzt und software geschrieben und das
6:32
war dann so richtig so. Ich weiß nicht, hab dann wollte
6:35
anfangen zu implementieren, die Funktion dann so AH da finden
6:38
des da finden des ich so oh Scheiße bleib Blog, da hast du
6:42
mich so dann gab es teilweise sowas wie irgendjemand guckt
6:47
sich n commit an ne oder guckt auf den Code er so hä wo ist
6:50
denn hier n Test? Hier ist kein Test.
6:51
Warum gibt es ja keinen Test dazu ist dann der hat geguckt
6:53
wer das committed hat ist da hingegangen hat gesagt EY hier
6:55
gibt es keinen Test, das können wir direkt nochmal löschen
6:57
nochmal neu schreiben ne also ohne Test wir haben wir machen
7:00
hier Test Driven Development und da ist kein Test dazu also ne
7:02
dachte ich auch so OK alter krass.
7:04
Das bleibt mal locker ne so. Also man kann es halt auch.
7:08
Ich sag mal übertreiben, aber es ist ja nicht komplett daneben
7:13
gegriffen würde ich sagen ne, weil Tests sind halt wichtig,
7:17
das wissen wir beide und das sagen wir auch immer ne.
7:20
Ja, und Testing Development ist ja auch ne Sache, für die wir
7:23
stehen, die wir auch selbst praktizieren.
7:27
Nennt man das Praktizieren also schon uns nach diesem Modell,
7:31
also nach dem Modell arbeiten? Aber es ist halt krass, denn zu
7:34
sagen, ja, hier kannst du alles wegschmeißen, weil der Test war
7:37
nicht vorher da. Und wenn du ihm hier Nachhinein
7:39
implementierst, dann schreibst du n Test für deine
7:41
Implementierung, aber nicht für deine Anforderungen.
7:43
So nach dem Motto, So würde ich das jetzt mal deuten, ne?
7:45
Das war auf jeden Fall, das ist schon extreme.
7:49
Also das war jetzt im Endeffekt genauso der, wie nennt man das
7:51
so, der Konsens, der dahinter gesteckt hat, so die Aussage ne,
7:54
und das fand ich dann auch schon n bisschen krass, ne also aber
7:57
trotzdem, das war du musst dir vorstellen, das war für mich so
8:00
die. Eben die Begegnung mit Test
8:02
Driven Development so n bisschen, wo ich mir so dachte.
8:06
Wow, wo bin ich denn hier reingeraten, aber es ist ja
8:09
nicht verkehrt ne, also an sich erstmal Test driven development
8:12
ist ne coole Sache, aber testschreiben an sich ist halt
8:15
auch wichtig ne und jetzt kann man sich natürlich fragen, OK
8:18
warum macht man das überhaupt ne weil ne warum hat jetzt zum
8:21
Beispiel der eine Typ da so warum es der so eskaliert weil
8:24
es keine Tests gab so nach dem Motto und.
8:28
An sich, wenn man es jetzt kurz fasst, ist es natürlich erstmal
8:31
liegt auf der Hand ne, dass man gucken kann, ob die Software die
8:34
man halt geschrieben hat oder schreibt halt auch so
8:38
funktioniert wie man es halt eben erwartet, ne oder wie man
8:41
es erwarten würde und ich find aber das reicht eigentlich noch
8:45
nicht so richtig aus um zu sagen.
8:50
Das ist jetzt Erklärung genug, weil rein theoretisch kannst du
8:52
ja sagen, OK, die Software ist da und du kannst es irgendwie
8:54
manuell testen, ne also. Genau.
8:57
Wir reden ja schon über automatisierte Tests, dann am
8:59
Ende ne. Ja, also der wichtigste Punkt
9:02
also, den man jetzt vielleicht so auf Erster auf den ersten
9:05
Blick nicht sieht, weil, wie du schon meintest, das erste, was
9:08
einem einfällt ist, ich teste, ob funktional alles so läuft,
9:11
wie ich mir das vorstelle. Jetzt kann ja jemand sagen, gut,
9:13
die Software ist entwickelt, dann teste ich das manuell
9:15
durch, ich weiß es funktioniert und fertig.
9:18
Der viel entscheidendere Punkt, und das ist auch der Punkt, der
9:23
mich persönlich und ich denke, es geht dir da ähnlich, auch
9:25
immer zum Struggeln bringt, wenn es heißt, wir wollen noch Sachen
9:30
ändern, wir wollen Sachen umbauen, wir wollen vielleicht
9:33
neue Features hinzufügen, also quasi während der Zeit, wo sich
9:37
eine Software noch stark weiterentwickelt und ich mein
9:40
sie die wenigsten Projekte entwickeln sich nicht weiter,
9:43
also du hast immer diesen Moment wo du sagst, ich änder mal was
9:46
ich refact da mal was. Und dann ist das mit dem
9:49
manuellen Testen halt so ne Sache.
9:51
Ne, weil du jetzt auch schon automatisierte Tests
9:53
angesprochen hast. Du kannst es nicht jedes Mal
9:55
wieder testen und das ist genau der Punkt wo die Tests dann so
9:59
und gerade die automatisierten Tests so wirklich glänzen.
10:02
Sie zeigen nicht nur, dass alles funktioniert zu dem Zeitpunkt wo
10:07
ich es geschrieben habe ne, also ich implementier ein feature,
10:09
ich schreib n test es funktioniert, das kann ich auch
10:12
manuell machen zu sehen dass es funktioniert.
10:15
Viel wichtiger ist doch zu sehen, dass alles andere noch
10:18
funktioniert, was ich bisher gemacht hab.
10:20
Das alles im Zusammenspiel funktioniert, weil nichts ist
10:24
schlimmer als kein Vertrauen in deine Entwicklung, in deine
10:27
Software zu haben und das ist nämlich der große Punkt, den die
10:31
Tester mit sich bringen, dass du dein Vertrauen in deine
10:35
Entwicklung, in deine, in deinen Code quasi erhöhst.
10:39
Ja, ich hab auch mal so. Übersichtlich.
10:41
Das ganze. Machst halt ne.
10:42
Ich hab mal so ne auch so ne krasse Story gehört da.
10:45
Das ist so n bisschen abseits von einer Softwareentwicklung
10:48
gewesen. Es war quasi so aus der Uni,
10:50
aber da wurde halt auch so n bisschen Software entwickelt,
10:52
aber jetzt nicht im Bereich Informatik oder so ne, sondern
10:55
es war quasi n anderer Fachbereich würd ich sagen ne
10:58
aber da war halt auch wurde halt auch Software geschrieben so ne
11:00
ich nenn es jetzt mal n Hobbycoder der das gemacht hat
11:04
und mit der Person mit der ich mich unterhalten hatte die.
11:07
Hat er dann immer gefragt, ne, also das war so die Story ne so
11:10
nach dem Motto kannst du es mal testen und dann hat die Person
11:13
das getestet ne und dann immer manuell und dann gab es wieder
11:16
sowas wie ja ich hab ne neue Änderung gemacht.
11:18
Kannst du es mal wieder testen? Ja, ich kann es testen, ja klar,
11:21
kein Problem, ja warte mal, aber jetzt geht hier was nicht so
11:24
also das heißt es wurde quasi eine Seite der Software
11:26
angefasst und auf einer anderen Seite ging irgendwas nicht, ne?
11:29
Ja gut, das ist ja super klassisch, das ist ja jetzt
11:31
nicht so was. Wie kann denn das passieren,
11:34
sondern das ist die Realität, ja, jedes Daily Business.
11:37
Am Ende, und das krasse war, dass die Person, die das erzählt
11:40
hat, auch immer dann so richtig so, also am Anfang war es ja
11:43
noch in Ordnung, ne so, aber dann testest du es das.
11:47
Dritte mal, das vierte Mal. Irgendwann bist du beim fünften
11:50
Mal und denkst dir so, warum muss ich denn, das dauert ja
11:52
auch alles und ich dacht mir so ja genau danke, dass du als
11:55
außenstehende Person in der Softwareentwicklung verstehst,
11:58
die so manuelle Tests halt nicht ausreichend sind und blöd sind,
12:01
ne, aber weil du meintest ne. Man muss ja also ne manuelle
12:06
Testen, reicht nicht aus, automatisiert Vertrauen in die
12:09
Softwareentwicklung schaffen, sozusagen in die eigene
12:11
Software. Und ich weiß nicht, ob, also was
12:14
heißt, ich weiß nicht. Also sicherlich hast du es auch
12:16
schon n paar mal gehabt so wenn du Software schreibst und keine
12:20
Tests hast und dir dann so denkst so OK, du hast irgendwann
12:25
so n mulmiges Gefühl und denkst dir so OK ich schreib jetzt noch
12:29
ne Zeile und noch ne Zeile und reitest dich quasi immer tiefer
12:32
in die Scheiße rein sag ich jetzt mal.
12:35
Weil du halt irgendwann dir denkst, OK, ich weiß jetzt nicht
12:40
so richtig, ob das jetzt noch funktioniert.
12:41
Genau von diesem Beispiel auch ne so, du hast keine Tests, du
12:44
bist irgendwie angewiesen, dass du es dann vielleicht manuell
12:46
testest. Aber je länger so und dann n
12:49
Projekt dauert und je größer der Code wird, desto mehr oder desto
12:53
schlimmer wird es ja, dass man irgendwie.
12:56
Sich denkt verdammt, funktioniert das noch oder hab
13:00
ich irgendwas übersehen? Dann gibt es n bugreport oder
13:02
sowas ne irgendwie ne Bug Meldung den man dann irgendwie
13:05
in irgendeiner Hektik fixt oder irgendwie sowas ne und dann halt
13:09
irgendwie wieder was übersieht oder so ne und ohne diese Tests.
13:13
Also du hast ja die ganze Zeit im Hinterkopf ohne Tests Scheiße
13:17
funktioniert das noch, hoffentlich hab ich jetzt nicht
13:20
irgendwas anderes kaputt gemacht ne oder bei einer beim
13:22
Refactoring oder so und damit man genau dieses.
13:26
Dieses mulmige Gefühl am Ende sozusagen rausklammern kann ne,
13:30
dafür ist es ja wichtig, dass man eben diese Testzeit hat oder
13:33
gerade diese automatisierten Tests.
13:36
Ja, also da ich find, das ist so, das fühlt sich halt so an,
13:39
als wenn man sich immer mehr selbst in die Ecke drängt und es
13:42
gibt irgendwann keinen Ausweg mehr, ne je länger das Projekt
13:45
läuft, je größer es wird, kommst du halt an einem Punkt, wo du
13:48
einfach nicht mehr weißt, wie der Stand der Software ist.
13:52
Also im Sinne von. Wie gut ist sie gerade, wie
13:55
stabil ist sie, funktioniert alles und ich mag das auch
14:00
mittlerweile so seit den letzten Jahren halt überhaupt nicht,
14:03
wenn ich keine Tests hab, wenn ich nicht ne Testumgebung hab wo
14:06
ich Sachen abtesten kann, weil das fühlt sich an wieso im
14:09
Dunklen tappen so ne also so wirklich als wenn du kein Licht
14:13
hast und du so mit der Hand vorweg denn irgendwie abtastest
14:16
und hoffst noch in die richtige Richtung zu laufen war n
14:18
bisschen überspitzt gesagt, aber so kann sich das dann irgendwann
14:21
anfühlen, weil du nicht weißt. Funktioniert noch alles
14:25
klassisch so refactoring? Ja, du refact das was und baust
14:29
irgendwo n Schnitzer ein, keine Ahnung, es ändern sich Eingabe
14:32
Parameter so von Funktion und du hast es nicht angepasst.
14:35
Du gibst vielleicht noch n alten Wert rein, gleicher Datentyp es
14:38
gibt keinen Fehler ne es läuft die Software startet es läuft
14:41
alles aber du rechnest jetzt mit falschen Werten beispielsweise.
14:45
Ne so. Ja und würdest dann halt zum
14:47
Beispiel mit Test sehen können. Ey warte mal, das stimmt nicht,
14:50
was du mir da gibst. Das kann nicht sein
14:52
beispielsweise. Es ist ja auch nicht so, dass
14:54
man sagt, OK, pass auf, ich bin jetzt irgendwie, also wenn du
14:57
deinen eigenen, also deine eigene Software schreibst in
14:59
Anführungsstrichen, die du halt in und auswendig kennst, mag das
15:02
noch mal das eine sein, aber komm mal irgendwie in.
15:06
Neues Projekt rein wo du den Code nicht kennst, wo es keine
15:10
Tests gibt, wo jemand sagt und jetzt implementier mal das und
15:13
das Bitte oder verändere diese Funktionalität dahingehend, dann
15:17
hast du nämlich irgendwann n Problem, weil du dir denkst OK
15:19
pass auf, ich hab jetzt das implementiert, ich hoffe es ist
15:23
richtig ich hab keine Tests an denen ich das testen kann ne im
15:28
Optimalfall fängt man dann einfach an für sich selbst
15:30
einfach n Testframework zu nehmen und Tests zu schreiben,
15:33
aber angenommen du machst es nicht.
15:35
So wo, wo fängst du an zu testen?
15:36
Ne, also du musst es ja irgendwie verifizieren und
15:40
angenommen du willst irgendwie keine Ahnung was irgendwas mit
15:44
dieser Software erreichen, was vielleicht irgendwie ne gewisse
15:47
kritische Sache hat, dann kannst du es ja nicht einfach so.
15:50
Ja ich probier es mal. Ach ist schief gegangen,
15:52
funktioniert ja wohl noch nicht richtig, die Software also ach
15:55
so übrigens ist kaputt, sorry es war wichtig oder blöd so weißt
15:59
du, das ist halt kannst du ja dann auch nicht machen.
16:02
Und das ist halt das Problem. Solche Sachen passieren halt
16:06
einfach. Ich meine, das ist ein recht
16:07
aktuelles Beispiel, wir haben ja jetzt für das Turnier, was wir
16:10
angesprochen haben, wieder ein Minigame geschrieben, das ist ja
16:13
quasi unser 4. Gewinnt Turnier in einer
16:16
Neuauflage, Wir haben was gelernt, 4 gewinnt Extreme und
16:20
das Ganze haben wir ja mit Go do entwickelt, das ist auch
16:23
wirklich ein Cooles, eine coole Engine, so ein cooles Framework
16:27
und wir. Wir haben aber diese Minigames,
16:31
die sind ja wirklich nicht sehr umfangreich, ne.
16:33
Und trotzdem, wenn wir Sachen Refactern und wir haben da
16:36
aktuell keine Tests, dann hatten wir halt auch den Fall, dass wir
16:39
zum Beispiel was nicht richtig refacterd haben, nicht
16:41
vollständig, dass wir nicht gesehen haben, paar Sachen gehen
16:43
nicht und beim Spielen merken wir so auf einmal, Hey, warte
16:46
mal dieses eine Feature, das das sieht irgendwie buggy aus was da
16:48
los. Nachgeguckt haben es gefunden
16:51
Guthaben wir gefixt, richtig, aber es muss ja gar nicht erst
16:54
so weit kommen. Deswegen war unser erster
16:56
Gedanke, ey, nee, wir müssen jetzt gucken, unterstützt Godo
16:58
zum Beispiel so N Unit Test Framework ja wir brauchen Unit
17:01
Tests für so ne Funktion, bestes Beispiel es passiert ja auch bei
17:04
kleinen Projekten schon, ja genau, also das ist ja wirklich
17:07
nicht zu vernachlässigen, ne und seit dem Moment wo das passiert
17:11
ist war beim Code wieder so oh mein Gott.
17:16
Jetzt aufpassen, jetzt jeden Schritt überwachen.
17:19
Hier, so weißt also weil. Halt deine Zuversicht, dein
17:22
Vertrauen massiv sinkt dann. Richtig.
17:24
Und da dafür, dass dieses Vertrauen steigt, gibt es halt
17:28
eben die Tests. Ne, damit wir jetzt noch mal so
17:30
n bisschen auch weiter kommen, nur das Problem ist, dass es
17:33
halt auch dazu kommen kann, dass selbst wenn du Tests hast, dass
17:37
sozusagen das Vertrauen gemindert werden kann, ne, also
17:40
angenommen du hast Tests für deine Software, die sind da, die
17:43
laufen so ne. Mehr oder weniger.
17:45
Aber du hast halt welche, die du laufen lassen kannst.
17:47
So nach dem Motto Ne und es ist halt auch möglich zu sagen, OK,
17:53
du hast diese Tests in deiner Software drin, die dir helfen
17:57
sollen und trotzdem sorgen diese Tests dafür, dass du beim
18:01
entwickeln dich nicht mehr sicher fühlst.
18:03
Fühlst. So und dann ist halt immer die,
18:05
also dann ist halt die Frage so OK.
18:08
Wie geht denn das überhaupt? Weißt du also, man kann sich
18:10
jetzt hinstellen und sagen, Hey, ihr habt doch gerade gesagt, OK,
18:13
Tests sind super wichtig, Tests schaffen das Vertrauen in die
18:16
Softwareentwicklung, dass der Code halt richtig läuft und so
18:18
weiter und jetzt wollt ihr mir im nächsten Schritt wiederum
18:21
erklären, dass aber wenn du Tests hast, die das Vertrauen
18:24
wiederum mindern oder mindern können, ne ja, und das ist ja
18:28
jetzt eigentlich genau der Knackpunkt der Folge, dann am
18:30
Ende. Genau, und das ist jetzt so wie
18:34
du sagst, der Knackpunkt, weil. Nicht jeder Test ist n guter
18:37
Test und nicht jeder Test hilft dir.
18:38
Also einfach nur Tests schreiben und selbst wenn sie, also ich
18:42
mein jetzt nicht Test die nichts testen, ja sowas hab ich auch
18:45
schon oft gesehen wo du denkst OK und was testet der Test jetzt
18:48
ab? Na ja das und das Na ja gut das
18:51
bringt aber der Software keinen Mehrwert also du hast eigentlich
18:53
nichts geprüft, so wirklich ja gibt es auch nee wir reden schon
18:56
von Tests die n Sinn haben und die auch Funktionalitäten
19:00
abtesten aber. Das bedeutet nicht zwangsläufig,
19:05
dass es dir hilft, weil bestes Beispiel haben wir auch schon n
19:08
paar mal diskutiert, sind flaky Tests und das klingt immer so.
19:13
Ja hä nee warte mal. Wenn ich jetzt gerade wenn ich
19:16
so einfache Tests schreibe, naja, die sind schon sehr
19:19
deterministisch in dem Sinne, dass sie immer grün sind oder
19:22
immer rot. Ja, und flaky Test bedeutet ja,
19:26
dass er ab und zu auch mal den anderen Zustand einnimmt.
19:29
Ja, also beispielsweise er läuft 10 mal grün und dann einmal rot
19:33
ist der bessere Fall 10, mal rot, einmal grün wäre natürlich
19:35
noch schlimmer, ne, also dann wirst du wahrscheinlich gar
19:37
nicht erst in die Bredouille kommen, die wir jetzt erklären,
19:40
was n flaky Test mit sich bringt, ne weil wenn er jetzt
19:42
sag ich mal sehr oft rot ist, wirst du es ja schnell merken
19:45
oder nicht akzeptieren können das Verhalten Problem ist ja
19:49
eher wenn er nur ganz selten. Mal Rot läuft ja und magst du
19:54
das Mal erklären? Also was was stört dabei so
19:57
extrem? Also ich kann auf jeden Fall mal
20:00
n Beispiel bringen von dem was ich erlebt hab.
20:02
Zum Beispiel mal. Also wir hatten auch, ich weiß
20:04
nicht, es war glaub ich n so n Backend mit irgendwelchen API
20:08
calls also wir hatten da ne API dran an diesem Backend ne so ne
20:11
API Schnittstelle oder warte API Schnittstelle Entschuldigung ich
20:15
wollt gerade sagen. Ey, mein Auge zuckt schon.
20:19
Abi Triggert ja n bisschen. Auf jeden Fall gab es dann da
20:23
halt eben auch Tests und wir haben dann einfach ne gab
20:27
irgendwie neue Funktionalität, so das typische ne du schreibst
20:30
dann Test damit du weißt OK die Funktionalität funktioniert auch
20:32
so wie man sich das eben vorstellt und so weiter so und
20:35
dann haben wir halt eben ne diesen Test laufen lassen haben
20:38
der war rot, wir haben implementiert, der war
20:40
vielleicht immer noch rot weil wir es noch nicht richtig
20:41
implementiert haben, irgendwann war er dann halt eben grün so
20:44
dann war cool wir so OK weiter. Nächsten Endpunkt ne haben wir
20:49
nächsten Endpunkt aufgebaut, auch wieder Test dazu und so
20:51
weiter lief auch wieder grün so das haben wir quasi für einen
20:54
ganzen Controller gemacht. Ne also n Controller mit
20:56
mehreren Endpunkten, zum Beispiel Get was auch immer ne
21:00
so und dann haben wir irgendwann gesagt ja alles klar cool, das
21:03
lief ja mal. Alle Tests waren Grün komm jetzt
21:06
können wir Committen und pushen lassen noch mal alle Tests
21:08
laufen, wir alle Tests laufen lassen Test war rot wir so hä OK
21:12
also. Keine Ahnung, wir hatten da,
21:13
sagen wir mal 1000 Unit Tests so nach dem Motto Ne ich spinne
21:16
jetzt spinne jetzt einfach mal ne Zahl zurecht und dann war
21:19
halt einfach so ein Test oder 2 Tests waren rot ich so hä wieso
21:23
waren sie? Wir sind jetzt 2 Tests rot haben
21:25
wir OK warte wir haben bestimmt irgendwas kaputt gemacht krass
21:28
dann haben wir vielleicht irgendwo haben wir irgendwo ne
21:29
Funktion angefasst aus einem aus einem Service der schon irgendwo
21:32
verwendet wird und deswegen weil wir den verändert haben ist n
21:34
anderer Test rot geworden irgendwie sowas ne keine Ahnung.
21:38
War aber nicht der Fall, sondern wir haben gemerkt, OK, warte mal
21:40
den einen Test den wir gerade geschrieben haben vor einer
21:43
halben Stunde, der ist jetzt wieder rot.
21:47
OK, den lassen wir noch mal laufen, der ist grün, denkst dir
21:49
so hä was zur Hölle passiert hier gerade und dann kannst du
21:52
zum Beispiel auch so, ich nenn es jetzt mal Tricks anwenden und
21:54
sagen OK ich nehm mir jetzt das sind so annotations, dass du
21:57
sagst oder ne es gibt dann verschiedene Frameworks, dass du
22:00
sagst lass den Test einfach mal 1000 mal laufen und dann hast du
22:02
gemerkt, wenn du den Test 1000 mal laufen lässt.
22:05
Wird er halt so. Keine Ahnung. 5 mal rot oder so
22:08
ne von 1000 malen, das ist genau der Punkt den du ja meintest wo
22:11
du denkst. Was zur Hölle ist hier gerade
22:14
los, was passiert hier gerade ne?
22:17
Das können ja verschiedenste. Es kann ja verschiedenste
22:20
Auswirkungen haben, wie zum Beispiel du hast irgendwo hatten
22:23
wir schon mal drüber geredet, irgendwie n Singleton, der sich
22:26
aufbaut, der quasi als einzelner Test, wenn du ihn laufen lässt,
22:28
gibt es nur dieses eine Single Objekt, was dann quasi auch nur
22:31
dementsprechend mit den Daten befüllt wird, die du gerade
22:34
haben möchtest. Oder du hast n timingverhalten
22:36
oder irgendwie sowas wie irgendein Emitter.
22:39
Weißt du wo du so ne so so Signale sendest die du dann.
22:43
Dem anderen Test quasi schon bekommst und dann irgendwie
22:46
drauf reagierst oder so richtig klassische Side Effects dann
22:49
über die Tests genau genau, Side Effects ist eigentlich n guter
22:53
gutes Stichwort ne, aber so was kommt dann dazu, dass deine
22:57
Tests halt eben flaky werden und das bedeutet ja, dass du dann in
23:01
diesem Moment schon dir denkst, scheiße, was hab ich denn jetzt
23:04
gerade implementiert? Also du du, du kriegst ja direkt
23:07
erstmal. Du bist ja zuversichtlich, dein
23:09
Test sind Grün, auf einmal wird der Test rot und du denkst dir
23:11
so. Moment, und dann kann es ja noch
23:15
so weit gehen, dass du dir denkst, warte mal ganz kurz, wir
23:18
haben die anderen Tests ja genauso geschrieben, also
23:20
vielleicht sind die auch irgendwie flaky, wer weiß das
23:23
schon, also weißt du, und dann fragst du dich, im nächsten
23:25
Schritt ist meine Software eigentlich überhaupt richtig
23:29
oder nicht so? Weil wenn du deine Tests hast,
23:31
die dir sagen es ist gerade rot, dann ist es halt.
23:35
Dann dann hinterfragst du halt auf einmal so viel, was dein
23:38
Code vielleicht irgendwie macht. Ne, also es könnte ja sein, dass
23:41
du sagst, wenn der Test wirklich vielleicht manchmal rot ist.
23:43
Vielleicht ist meine Implementierung auch manchmal
23:45
falsch oder du sagst sowas wie ja gut, ey, dann weißt du, es
23:50
kommt zum Beispiel einer an und sagt, Nee, Pass auf, gar kein
23:52
Problem, dieser Test, der ist schon seit Monaten flaky mach
23:56
dir darüber keine Sorgen, laufen ja lass einfach noch mal laufen,
23:59
mach dir keine Sorgen, die Implementierung, die passt
24:02
schon. So, und dann kommst du an einem
24:04
Punkt, der halt irgendwie ein bisschen ungeil wird, ne?
24:08
Na ja gut, du hast halt das Problem, dass du ein falsches
24:12
Vertrauen aufbaust in dem Moment, beziehungsweise es ist
24:16
begründet das Vertrauen in dem Moment, weil du weißt, es ist
24:19
richtig implementiert. Das ist vielleicht jetzt
24:21
irgendwie in der Testumgebung ne, dass du so Side Effects
24:23
hast, dass es wirklich nicht an deinem Code liegt.
24:26
Kann ja sein, dass. Sondern dass deine Testumgebung
24:29
ne Convicard Side Effects hat und dann das einfach nicht
24:32
richtig sag ich mal einen von 100 Fällen oder was du vorhin
24:36
meintest nicht läuft. So natürlich ist es naheliegend
24:40
zu sagen, Nee komm, wir haben jetzt Projektor, wir haben keine
24:42
Zeit so der läuft das ist richtig ne wir haben es manuell
24:45
getestet, die Tests fällen ja nur keine Ahnung wenn ne ein
24:48
Prozent Wahrscheinlichkeit oder so.
24:50
Lass einfach noch mal laufen, das kann so weit gehen, wie die
24:53
Pipeline rot komm schnell, Trigger noch mal, das läuft beim
24:56
nächsten Mal durch, ist durchgelaufen alles gut.
24:58
Das Problem ist, dass du darauf jetzt vertrauen aufbaust und es
25:04
ja aber sein kann, wenn du Änderungen einspielst.
25:07
Ne das sagst ich änder n feature ab oder ich bau n neues ein.
25:11
Und vielleicht an anderen stellen Tests rot werden oder
25:15
der Test jetzt rot ist, der sonst flaky ist.
25:18
Und du sagst ach na ja gut, das ist der Flaky Test Come on noch
25:20
mal. Also was garantiert dir und das
25:25
ist jetzt der Knackpunkt dabei, was garantiert dir, dass es
25:28
immer noch ne Condition ist, die dazu führt, dass der Flaky ist
25:32
ne, dass halt irgendwelche Side effects da sind oder vielleicht
25:36
jetzt doch was kaputt ist? Jetzt hast du dieses falsche
25:39
Vertrauen zu sagen. Ach flaky ja sowieso ne Ausrede.
25:42
Komm Lars, Wir haben keine Zeit, der ist Flaky der läuft wieder,
25:44
aber was wenn nicht was wenn da jetzt auf einmal wirklich
25:47
irgendwas kaputt gegangen ist? Ja, zum Beispiel ist halt nicht
25:50
das große Problem, weil dann hast du nämlich vielleicht
25:52
irgendwann, denkst du dir so, warte mal da in dem Test.
25:54
Das war auch Flaky, da haben wir auch mit irgendwelchen Signalen
25:56
rumgespielt, dann wird das hier ja auch so sein, aber wenn du
25:59
dann vielleicht wirklich das echte Verhalten hast, dass zum
26:01
Beispiel Signale richtig gefeuert werden in deinem Code,
26:04
aber manchmal eben falsch, und deswegen ist der Test nicht
26:07
flaky. Sondern korrekt.
26:08
Falsch so nach dem Motto, dann hast du halt irgendwann n
26:12
Problem und es kann zum Beispiel auch dazu führen, dass du sagst,
26:15
OK, pass auf, aber was ist denn die Auswirkung?
26:17
Ja OK, dann ist der Test flaky fix ihn halt erstmal kann man
26:20
dazu sagen Flaky Test kann schon echt lange dauern bis man ihn
26:25
eventuell gefixt bekommt, also bin ich.
26:27
Fertig. Und deswegen versuchen ja auch
26:29
viele, dem aus dem Weg zu gehen. Genau so.
26:32
Und dann sagt man aber OK. Ich also, die nehmen wir mal die
26:38
Situation an, man geht dem aus dem Weg und lässt diesen flagy
26:40
Test drin, ne weil wir dabei sind und sagen Lösch deine
26:43
Tests, du lässt den drin, die Pipeline läuft, vielleicht hast
26:47
du ne Pipeline die dauert ne Stunde und dann irgendwann ist
26:49
auf einmal nach 40 Minuten Wartezeit auf einmal merkst du
26:53
oh die Pipeline ist rot ja ist n flagy Test lass noch mal laufen
26:57
so dann lässt du es wieder laufen, es heißt grün und dann
27:00
kann es deployed werden also es ist Zeit es ist Geld.
27:03
Und im Endeffekt kannst du dann auch einfach sagen, OK, pass
27:06
auf, Lösch einfach den Test weg, wenn dein, wenn dein dein Test
27:09
wirklich so flaky ist und du keine Zeit hast dich darum zu
27:12
kümmern, dann lösch den halt weg und wenn man sich jetzt
27:15
hinstellt und sagt Na ja gut, aber ey ganz ehrlich, es könnte
27:18
ja sein, dass der Test irgendwann mal wirklich n echten
27:20
Fehler abfängt, dann kann man auch sagen, OK dann wenn der
27:25
Fehler wirklich auftritt, den du irgendwie vielleicht
27:28
möglicherweise gerade befürchtest.
27:30
Und vielleicht ist es auch nur so n.
27:33
Du hast gar keine Idee was für n Fehler auftreten könnte, dass
27:36
dieser Test vielleicht wirklich wichtig wäre, aber wenn, selbst
27:41
wenn das Auftritt dann keine Ahnung implementier n Test
27:45
implementier die Funktionalität dazu und zwar etwas was halt
27:49
nicht flake ist, aber vorher zu diesem Zeitpunkt, wenn es also
27:51
wenn es soweit ist, aber zu dem Zeitpunkt Lösch einfach den Test
27:54
weg, weißt du? Ja und?
27:59
Noch mal, um das Ganze zu motivieren, warum man also warum
28:03
soll ich den nicht löschen? Ich kann den fixen, weil du
28:05
meintest ja das kann sehr umfangreich sein, da muss man
28:08
sich ja nur vorstellen, angenommen ich hab ne
28:11
Testumgebung und zum Beispiel was du meinst bei den Controller
28:15
und ich hab jetzt ne gewisse Art mir überlegt wie ich das testen
28:18
kann mit den Signalen mit den Calls wie auch immer ne.
28:21
Jetzt stell dir vor, der Test ist Flaky so, das sind so die
28:24
ersten, bei den anderen ist es noch nicht aufgefallen, aber du
28:27
verwendest immer so die gleiche Art und Weise Sachen Abzutesten
28:30
jetzt kann es sein um das zu beheben musst du deine komplette
28:34
Grundannahme wie dein Test Framework aufgebaut ist ändern.
28:39
Du musst vielleicht ganz anders die Sachen Abtesten, sprich dein
28:43
komplette Test, dein komplettes Test Framework bezüglich dieses
28:47
Features oder dieser diesen Teil der Software.
28:49
Ne, wenn es jetzt um zum Beispiel die Controller geht,
28:52
komplett refact dann und neu neu schreiben oder oder sehr stark
28:56
umschreiben nur mal um zu motivieren, dass es halt auch
28:59
wirklich viel Aufwand bedeuten kann um einen so n flaky Test
29:02
dann wegzukriegen, weil die anderen vielleicht noch nicht
29:04
flaky sind, da funktioniert es halt irgendwie noch, aber du
29:06
merkst halt ey um das beheben zu können.
29:08
Müssen wir ne komplett andere Grundannahme treffen und die
29:11
Test of Suite anders aufbauen und True Story, das hatten wir
29:15
im Projekt zusammen schon ne, dass wir gemerkt haben, ey warte
29:18
mal hier in dem und dem Projekt, das wird uns nicht ins Ziel
29:22
bringen, also haben wir die komplette Testsuite da
29:24
umgeschrieben. Ja, das war also das.
29:27
Ist das ist ja die Realität, ne, also das heißt ja nicht flaky
29:30
Test. Ja dann schreib den Halt um, ich
29:32
mein die sind flaky nicht weil weil du irgendwie keine Ahnung.
29:36
Wieder Bock drauf. Hast du mal blöd gesagt, sondern
29:39
weil halt vielleicht irgendwelche Kombination an Side
29:42
Effects zusammenspielen und das dann halt einfach nicht
29:45
gewährleistet, dass es immer die gleichen Bedingungen hat am Ende
29:48
und das ist das das passiert schnell.
29:50
Ja, definitiv. Also ich würd auch zum Beispiel
29:53
sagen, OK, es ist durchaus wertvoll zu sagen, warum ist der
29:56
Test flaky ja nachgucken und verstehen warum es so ist, weil
30:01
es hilft ja und bringt dich selbst nur weiter.
30:04
Das ist halt wichtig. Aber wir gehen ja jetzt von der
30:07
Annahme aus, dass man wirklich sagt, OK, der Test bleibt drin
30:12
und er verzögert regelmäßig, fängt an, das Vertrauen
30:16
sozusagen der Entwickler oder der Entwicklerin Halt eben zu
30:20
untergraben in den Code. Wenn das der Fall sein sollte,
30:23
dann Lösch den Test raus, wenn du die Zeit dafür hast ihn zu
30:26
fixen und der Sache auf den Grund zu gehen, vielleicht das
30:28
Test Framework noch mal n bisschen zu überarbeiten
30:30
beziehungsweise die Art und Weise wie getestet wird.
30:33
Dann macht das auf jeden Fall. Aber sollte das nicht der Fall
30:36
sein, dann löscht den Test halt einfach raus, weil dann.
30:38
Brauchst du ihn nicht. Da kommen wir nämlich auch zu
30:40
einem ganz anderen wichtigen Punkt, um mal so ein bisschen
30:43
von den flaky Tests wegzukommen, weil es gibt natürlich auch
30:45
andere Gründe, weil du ja meintest, die Pipeline läuft
30:48
eine Stunde und dann merkst du es erst.
30:50
Musst du es noch mal laufen lassen, das heißt du hast halt
30:53
sehr. Also ne langsame Testsuite
30:57
klingt jetzt irgendwie fies. Ne, es kann ja einfach sein,
30:59
dass es eine sehr umfangreiche Testsuite ist.
31:02
Ne, gerade dieses du hast n neues Feature, schreib n Test,
31:05
schreib mehrere Tests Tests genau ab Bug ersten Test damit
31:09
du sag ich mal gewährleisten kannst, dass er nicht wieder
31:13
auftritt und der Fall ab sofort geklärt ist.
31:15
Das sind ja alles Gute, wie soll ich sagen Prinzipien.
31:20
Verhaltensweisen eines Coders oder einer Coderin zu sagen,
31:23
nein, ich möchte das so gewährleisten, das ist ja auch
31:26
richtig. Problem ist, wenn du jetzt immer
31:28
mehr Tests hast und vielleicht auch richtig teure Tests, ja,
31:31
also so E to e Tests ja auch Integration, Tests, also alles
31:35
was auch irgendwann Zeit frisst um das zu testen.
31:38
Und deine Pipeline sehr langsam wird oder umfangreich ist.
31:42
Ja, du kannst das natürlich irgendwann auf mehreren Ebenen
31:45
testen, das hatten wir ja auch, zum Beispiel in unserer Defops
31:47
Reihe, dass du sagst, im CI teil lass ich die Unit Tests laufen,
31:50
also dass du immer mehr Tests dazu packst Richtung Deployment,
31:54
um dann die absolute Gewährleistung zu haben, ne,
31:56
weil was ich auch erlebt hab und das ist jetzt der Punkt auf den
31:59
ich kommen möchte. Du hast viele viele Tests und
32:04
einige davon oder viele sind schon sehr lange in der
32:07
Software. Das heißt, die Laufen schon seit
32:10
Monaten grün, dass sich Leute denken, ja, müssen wir das noch
32:16
testen, also also, was bringt uns das, das war schon immer
32:19
grün, so ne, also da an an dem Teil machen wir doch auch gar
32:22
nichts mehr, ne, also auch jetzt noch mal zum Beispiel Richtung
32:26
manuelles testen, was du vorhin meintest.
32:28
Ja, dass jemand sagt so ja Mann, das hab ich doch schon fünfmal
32:31
getestet, dass du irgendwann lazy wirst und sagst.
32:36
Nee, warte mal, das dauert mir zu lange mit der Pipeline oder
32:38
das manuelle testen. Das gilt für beides.
32:40
Jetzt ne, lass doch, lass uns mal die Tests deaktivieren,
32:43
kommt die die laufen eh, die machen wir halt nur noch dann am
32:46
Ende noch mal zum Release oder was auch immer, also die
32:48
brauchen wir nicht immer mitlaufen lassen ne weil das Ey
32:51
ganz ehrlich das läuft seit 5 Versionen seit Jahren mal
32:53
überspitzt gesagt oder der manuelle Tester denkt denkt sich
32:56
ich hab das 100 Mal getestet es ist immer gleich es wird beim
32:59
101. Mal auch gleich sein ne und das
33:02
folgt daraus. Also dieses Verhalten folgt ja
33:05
daraus, dass deine Pipeline Quatsch, deine Testumgebung sehr
33:09
groß und langsam wird oder Wartungsintensiv zum Beispiel
33:11
auch ne und das ist halt n riesen Punkt, warum man auch
33:15
wieder sagen kann, macht es vielleicht nicht Sinn diese
33:20
Tests zu refactern und zu gucken, welche ich davon
33:22
wirklich noch brauche. Ja, ich meine gut, wenn du
33:25
sagst, du hast zum Beispiel deine Tests, die du halt einfach
33:28
eh immer deaktivierst, weil du immer sagst, die sind viel zu
33:32
langsam, dann. Wie gesagt, wenn du die Zeit
33:35
dafür nicht hast, dann lösch die halt einfach weg, weil sie dich
33:38
einfach, also entweder dich aufhalten oder du sie eh immer
33:42
nur deaktivierst. Also kannst du sie auch
33:44
weglöschen, weil Tests heißen auch gleichzeitig es ist
33:47
wartungsarbeit. Du musst bei Tests halt
33:50
irgendwie ne gewisse Wartung reinstecken und ich find das ist
33:54
auch n Punkt wo man auch durchaus mal sagen kann, weil
33:58
wir sind ja auch an dem Punkt, dass wir auch sagen Refactoring
34:00
ist wichtig im Code, genauso ist es halt.
34:03
Also Tests sind auch Code, also sollte man die auch refactern
34:06
ganz genau. Und wenn du jetzt aber zum
34:08
Beispiel Tests hast, ne, weil wir jetzt von wartungsintensiven
34:10
Tests gesprochen haben, du hast Tests wo du weißt wenn ich jetzt
34:15
ne kleine Änderung im Code mache, dann muss ich auf einmal
34:18
bei einer Codezeile muss ich 150 andere 150 Tests anpassen, nicht
34:25
nur den einen der sozusagen ich sag jetzt mal übertrieben für
34:28
diese Codezeile zuständig ist, sondern 150 andere Tests.
34:32
Wenn du das hast, ja, dann sind die Tests wahrscheinlich auch
34:37
nicht ganz so geil, ne? Also da kannst du dich schon
34:40
fast hinstellen und sagen, OK ey, lösch doch diese Tests weg,
34:42
weil diese Tests haben sich so extrem in deinen Code
34:45
reingebrannt, dass sie nicht mehr wirklich ein Verhalten
34:49
abtesten, sondern halt eher die Implementierung ne und ich finde
34:53
das ist auch wirklich tatsächlich ein richtig schmaler
34:55
und sehr sehr schwieriger Grad bei Test.
34:58
Beim Test schreiben wirklich zu sagen ich teste.
35:01
Die Funktionalität und nicht die Implementierung.
35:02
Man neigt schnell dazu, Implementierungen zu testen, das
35:05
heißt, wenn du deine Implementierung, du kannst ja 50
35:08
Art und weisen zum Beispiel implementieren, wie du etwas
35:11
sortierst. Es gibt so viele
35:13
Sortieralgorithmen, ne, wenn du aber wirklich sagst, ey ich
35:16
teste jetzt aber explizit, dass da Heep Sort verwendet wird
35:19
anstatt keine Ahnung Merch Sort oder irgendwas ne und du dann
35:23
aber sagst Ey Moment, aber wir brauchen jetzt aber noch viel
35:26
schnelleren Search Algorithmus. Sort Algorithmus sorry, dann
35:33
funktionieren Tests auf einmal nicht mehr, obwohl ja eigentlich
35:35
das Verhalten ist, wurde sortiert.
35:37
Richtig ist weißt du, das ist halt da, muss man halt auch
35:40
drauf achten und wenn du dann so n so so etwas hast wo du sagst
35:43
OK pass auf, ich ändere ne Kleinigkeit und super viele
35:46
Tests failen, dann sind deine Tests wahrscheinlich nicht so
35:48
gut also du machst den Riesenaufwand anstatt dann
35:50
einfach zu OK pass auf ich ich hau die weg so.
35:54
Genau. Und da schließt sich der Kreis.
35:55
Worauf ich hinaus wollte. Gut, dass du es angesprochen
35:57
hast, weil dieses Verhalten ich deaktiviere Test, weil etwas
36:00
langsam läuft und so resultiert ja auch daraus, dass ich
36:04
Altlasten mit Trage und ich nenn es jetzt mal provokativ
36:07
Altlasten wie du gerade meintest, so Tests.
36:09
Die eigentlich gar nicht mehr so richtig Funktionalität abbilden,
36:13
sondern vielleicht noch so Implementierungen, die drin
36:16
sind. Features ändern sich, ich
36:17
refector die Software und wie du meintest, da muss auch die Test
36:20
Suite refected werden ne es ist Schritt 1 zu sagen ich änder was
36:24
OK meine Tests sind noch grün, schritt 2 ist aber brauch ich
36:28
noch alle Tests davon bilden die noch überhaupt das Verhalten
36:30
sauber ab oder sind da jetzt testbei die zwar grün sind aber
36:33
eigentlich gar nicht mehr relevant sind?
36:35
Und da gibt es auch. Ne coole Denkweise zu sagen, es
36:40
ist jetzt grün. Es war also die Funktion
36:43
funktioniert so wie sie soll, ich refector sie funktioniert so
36:46
wie sie soll und ich guck jetzt die Tests durch, dann kann ich
36:49
ruhig Test die vermeintlich nicht mehr wirklich ne Rolle
36:52
spielen ja wirklich löschen, dass ich sage OK nee ich glaub
36:58
die brauch ich nicht mehr, das sieht nicht so aus als wenn die
37:00
jetzt wirklich noch Funktionalität abbilden im
37:04
Testsinne ne weil. Angenommen, dann tritt
37:07
irgendwann ein Bug auf, wird es leichter sein, den zu finden.
37:12
Also weil es ja, weil du ja einen definierten Zeitpunkt
37:14
hast. Ja, dass du sagst, okay, ich
37:16
habe jetzt meine Funktion, die funktioniert und falls denn doch
37:20
ein Bug kommt, schreibe ich einfach einen neuen Test statt
37:23
den alten irgendwie immer wieder umzubauen und irgendwie wieder
37:27
reinzuzwängen in mein neues Konstrukt.
37:30
Dass ich dann sage, OK, ich nehme in Kauf, dass irgendwas
37:32
nicht funktioniert, potenziell. Ja, es ist ja nicht
37:35
gewährleistet, dass es soweit kommt, und dann bin ich aber am
37:38
Ende schneller nicht die Altlasten zu verwalten und zu
37:41
erneuern, sondern dann zu sagen, OK, dann haben wir jetzt n Bug
37:44
und den fixen wir. Ja richtig, auf jeden Fall.
37:47
Und das ist meistens dann sogar am Ende sogar schneller unter
37:49
Umständen. Genau das, das klingt jetzt
37:51
erstmal, das muss man auch mal sacken lassen.
37:53
Das klingt n bisschen komisch, weil man sich so denkt, Na ja,
37:55
warte, aber der Bug kann gar nicht auftauchen, wenn ich ja
37:57
diese alten Tests noch hab. Nee, genauso ist es ja nicht,
37:59
weil die ja eventuell wirklich auf alte Konstrukte basieren,
38:03
alte Annahmen und gar nicht mehr so wirklich der aktuellen
38:06
Software entsprechen. Ja, richtig.
38:09
Und ich würd auch sagen, nicht nur veraltete Tests, sondern
38:12
vielleicht auch manchmal hab ich auch schon erlebt, man schreibt
38:15
irgendwie ne Funktionalität um und kommt dann dahin, dass du
38:18
vielleicht 2 Tests hast, die du anpasst an so nach dem Motto Ah,
38:22
ich hab jetzt hier was quasi verändert, ist ja durchaus
38:24
möglich, dass du keine Ahnung ne ne Änderung machst und dann
38:27
siehst OK meine Tests, also es ist n Tests rot ne bessere Weg
38:31
wär zu sagen erstmal pass ich meine Tests an, also meine
38:33
Erwartung und dann wirklich die Implementierung.
38:36
In der Realität sieht es oft so aus, dass du einfach erstmal den
38:38
Code anpasst und guckst. OK, was ist denn rot?
38:41
Dann guckst du dir Tests an und sagst Ah, diese 2 Tests sind
38:43
rot. Ja genau, weil da steht ja der
38:45
Test. Sagt das und das soll getestet
38:47
werden, ist ja jetzt nicht mehr soweit ich das verändert hab,
38:49
also passt du den Test an die Implementierung an was wo ich
38:53
sage auch unter Umständen durchaus in Ordnung ist, weil du
38:56
ja eigentlich im Normalfall und das jetzt wieder wichtig n
38:58
kleinen Scope hast wo du sagst eine kleine Änderung ein 2 Tests
39:04
failen so. Und du kannst so anpassen und
39:06
sagen, zum Beispiel sowas wie ne, wenn wir beim Sort Beispiel
39:09
sind. Du sagst du möchtest, dass es
39:11
andersrum sortiert wird, könntest du natürlich erst
39:13
deinen Test anpassen und sagen, ey das was ich erwarte nach der
39:16
Funktion ist, dass es absteigend sortiert ist, nicht aufsteigend
39:19
ne kannst aber auch erstmal die Implementierung ändern und dann
39:22
sagen ja ich hab es ja jetzt absteigend sortiert, also muss
39:24
ich das quasi mal im Test umdrehen und dann ist der Test
39:26
wieder grün ne so aber ich hab auch schon mal erlebt, dass dann
39:29
genau aus solchen Veränderungen 2 Tests eigentlich so gut wie.
39:33
Identisch waren zumindest von dem, was getestet wurde, aber
39:36
nicht von dem, wie der Test am Ende aussah.
39:38
Weißt du, und dann ist es wichtig, auch mal zu sagen, OK,
39:41
ich hab hier vielleicht gleiche Tests, die aber das, also
39:44
unterschiedliche Tests die das gleiche Abtesten sozusagen am
39:47
Ende ne, also vielleicht auch auf anderen Ebenen oder so ne
39:50
und da bietet sich dann halt auch mal an zu sagen.
39:52
Absolut Lösch die Tests, die. Redundant sind das brauchst du
39:55
nicht, das ist alles Wartungsarbeit am Ende die
39:57
hinterher. Runterfällt.
39:59
Genau also das über mehrere Ebenen ist n absoluter
40:02
Klassiker, dass du sagst, ich teste auf kleinster Ebene ab.
40:06
Das und das darf nicht passieren, dann also
40:08
beziehungsweise diese Eingaben sind nicht erlaubt,
40:11
beispielsweise so jetzt hast du auf einer höheren Ebene quasi
40:16
getestet, dass diese Eingaben niemals da reingehen können, nur
40:20
mal so n kleines konstruiertes Beispiel, dann hast du jetzt 2
40:23
Tests die in sich. Funktionalität abbilden, aber
40:26
irgendwo halt auch wirklich deine Implementierung und nicht
40:29
mehr die Anforderung oder die Funktionsweise ne und hast 2
40:34
Tests, obwohl das eine gar nicht eintreten kann, aber der Test an
40:37
sich ist ja trotzdem grün, weil er sorgt dafür, dass bei der
40:40
Eingabe n Fehler fliegt, zum Beispiel ja grün der obere Test
40:45
sagt diese Eingabe kann niemals sein, hast du abgetestet kann
40:48
nicht passieren. Und trotzdem stehen die beiden
40:50
Tests einzeln ja für ne gewisse Bedeutung, dass du sagst, ey,
40:53
den brauch ich doch, den Test. Aber eigentlich brauchst du den
40:56
unteren an der Stelle nicht, weil weil es ja gar nicht
40:59
passieren kann, weil du ja auf höherer Ebene das Abgetestet
41:02
hast. Jetzt ist es halt wie gesagt
41:04
immer n Trade auf und deswegen testen ist ne Kunst für sich und
41:06
man muss da auch viel Erfahrung sammeln.
41:09
Je nachdem, jetzt kann man ja sagen, ja, dann test ich nur auf
41:11
höchster Ebene. Mir ist egal wie das intern
41:13
aussieht, ich will das von außen wirklich grob, meine
41:16
Anforderungen funktionieren, da hat mir auch mal n ne Folge
41:19
gemacht mit der Testpyramide das alles immer natürlich n Preis
41:23
hat. Ne wenn ich jetzt sage ich teste
41:25
viel im Verbund wird es schnell auch sehr zeitintensiv und teuer
41:29
das ganze ne und. Dann kommst du vielleicht wieder
41:32
dahin, dass deine Testsuite irgendwann so langsam wird, dass
41:34
du irgendwann sagst, komm, die nehmen wir mal raus.
41:36
Ne, damit genau das geht gar keine.
41:39
Genau. Und dann kannst du die Tests
41:40
auch wieder löschen. So ne auf jeden Fall auf.
41:44
Also das ist auf jeden Fall wichtig, dass man sich halt auch
41:47
sagt, so als Fazit. OK, man darf auch Tests löschen,
41:51
es ist OK Tests zu löschen, wenn du einen gewissen Grund dahinter
41:54
hast. Ne wenn du jetzt zum Beispiel
41:56
sagst Ey das ist ne wirklich kritische wichtige Logik die ich
41:59
da hab und hier sind Tests dazu, dann lösch die Tests auf gar
42:01
keinen Fall, das ist ja wichtig so, aber wenn du keine Ahnung
42:04
diese Logik 5 mal abtestest so dann brauchst.
42:06
Musst du es aber auch nur einmal.
42:07
Lösch also die anderen 5 ne, das ist flaky hau das Weg, keine
42:12
Ahnung, musst du übermäßig viel Wartungsarbeit in bestimmte
42:15
Tests stecken, hau die Tests weg, das frisst einfach nur zu
42:18
viel Zeit, so ne sind sind die zu langsam Hau-Weg irrelevant
42:22
geworden, dann hau die Tests weg also man darf Tests löschen, das
42:26
ist wichtig, man sollte halt wie gesagt immer drauf achten, dass
42:30
Tests halt sinnvoll sind und halt auch sinnvoll bleiben, ne?
42:34
Genau also die große Take Home Message für uns und auch für
42:38
dich, liebe Zuhörer, liebe Zuhörer, ist einfach das Test
42:41
Suiten und die Tests einfach regelmäßig refacted werden
42:44
müssen, dass man immer wieder challengen muss, ob die Tests
42:47
noch sinnvoll sind oder nicht. Und was kann ich optimieren?
42:51
Ne um halt quasi nicht in so n Bottle neck zu kommen zu sagen
42:54
Ey jetzt dauert alles viel zu lange, jetzt sind die Entwickler
42:57
genervt davon, zum Beispiel schon.
42:59
Ja, ich würd auch noch ne Kleinigkeit noch sagen, weil das
43:02
liegt mir nur auf dem Herzen. Es gibt ja viele Metriken, wo
43:05
man zum Beispiel sagt, Ey hier keine Ahnung, deine Tests
43:09
Coverage, wie hoch ist die Coverage, wie viele Tests gibt
43:12
es eigentlich wurde die Testpyramide eingehalten, so
43:14
nach dem Motto Ne das sind alles irgendwie so.
43:17
Metriken oder ich sag mal so eine gewisse Art von Fokus auf
43:20
den ganz häufig irgendwie sozusagen geschaut wird.
43:24
Aber eigentlich finde ich, sind das völlige Bullshit, Metriken
43:26
mal wirklich ein bisschen provokativ das ganze
43:29
hinzustellen, sondern die wichtigste Metrik an dieser
43:31
ganzen Stelle ist, wie hoch ist dein Vertrauen in deinen eigenen
43:35
Code und wie stark kannst du dich darauf verlassen, dass
43:37
irgendwie Änderungen oder zum Beispiel bei Refactoring auch
43:40
nichts kaputt geht. Wenn du da sagst, ey, das ist
43:43
richtig, richtig geil und ich kann.
43:45
Mich vollends darauf verlassen, dann sind deine Tests richtig
43:49
geil. So richtig guter Punkt also.
43:51
Es ist viel aussagekräftiger, die Entwicklerinnen und
43:54
Entwickler zu fragen, wie zuversichtlich sie coden und was
43:58
zum Beispiel auch aussagekräftiger ist.
44:00
Wie oft steht denn deine Pipeline, wie oft failed denn
44:03
ein? Eine Integration oder ein
44:04
Deployment? Ja du kannst ja 100%
44:06
Testcoverage haben und trotzdem steht bei jedem dritten Lauf
44:09
deine Pipeline bringt dir also nichts, das ist so n so n flexen
44:14
ja guck mal 100% Test. Deckung was aber am Ende schon
44:18
symbolisiert so n bisschen uh weiß nicht ob das jetzt wirklich
44:23
gut ist was ihr da macht. So ne also bin ich ehrlich wenn
44:26
da wenn jemand mit sowas um die Ecke kommt bin ich immer erstmal
44:29
n bisschen skeptisch vielleicht unbegründet, aber weil das
44:32
sollte kein Maß sein sondern eher die beiden Punkte zum
44:36
Beispiel die ich gerade angesprochen hab.
44:39
Ja, hast du sonst noch n abschließendes Wort Fabi?
44:41
Sonst würde ich sagen, haben wir das Thema gut besprochen.
44:44
Bitte teste jetzt erst mal n paar Worte zu testen genau und
44:50
deswegen jetzt am Ende noch die Frage an dich, liebe Zuhörer,
44:53
liebe Zuhörer, was halt ist, was hältst du von Tests?
44:57
Testest du regelmäßig deine Software, hast du das was wir
45:00
geschildert haben mit unseren Erfahrungen schon mal selbst
45:02
erlebt? Wie stehst du zu den Metriken,
45:05
die Fabi gerade kritisiert hat? Das sind alles so Punkte, die
45:08
wir gerne, wo wir gerne in Austausch kommen würden, schreib
45:11
uns gerne zum Beispiel über die Podcast Mail, die findest du in
45:13
Show Notes über allen Plattformen kannst du uns
45:15
erreichen, wir werden auf jeden Fall antworten findest du auch
45:18
in den Show Notes die ganzen links ansonsten, wenn dir die
45:21
Folge gefallen hat du findest auch einen kleinen Spendling
45:23
wenn du uns unterstützen möchtest, dann vielen, vielen
45:25
Dank dafür. Vergiss nicht, den Podcast zu
45:28
abonnieren, falls du es noch nicht gemacht hast, lass gerne
45:30
eine Bewertung da. Das sind alles Punkte die uns
45:32
massiv helfen das Ganze hier weiter zu treiben und ansonsten
45:36
würde ich sagen, haben uns alle nächste Woche wieder habt eine
45:38
schöne Zeit bis dahin ciao ciao deine Coding Buddies.
45:42
Gemeinsam besser.