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.