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