Automatisierte Tests.

Herzlich willkommen in unserem Webcafé. Das ist unser wöchentlicher Podcast rund um die Themen Webentwicklung und Unternehmenskultur. Und mir gegenüber sitzt heute wieder virtuell der Kay. Hallöchen! Und auch Hallöchen an unsere lieben Hörer. Ja, ich bin der Felix und ich bin Geschäftsführer bei der GNAT-Systeme GmbH, wo der Kay Technical Lead ist und damit Ansprechpartner in allen technischen Fragen. Und wie jede Woche bringen wir uns immer ein leckeres Heißgetränk mit, wobei es im Sommer wahrscheinlich auch mal kalt sein darf, aber bisher war es immer heiß. Und Kay, ich habe ein Früchtetier heute dabei und lese dir mal gerade den Flavortext von der Packung vor,

weil ich den so gut finde. Oh, jetzt kommt es. Und zwar habe ich einen fruchtig-spritzigen Mix aus erntefrischen Himbeeren und Erdbeeren, abgerundet mit einem Mauch Vanille. Das überrascht mich schon. Du bist ja eigentlich gar nicht so der Früchtetyp. Ja, genau. Den habe ich eigentlich auch für die Kinder besorgt. Aber dann rocht er so gut, dass ich ihn doch selbst mal ausprobiert habe. Das sind ja ganz neue Sphären, in die du da aufsteigst. Willkommen auf der schönen Seite des Lebens. Was hast du mitgebracht? Ich habe passend dazu aus unserem Beutel-Altbestand eine Mischung aus Zitrone und Orange.

Hört sich auch gut an. Das sollte dich über die Sendung tragen. Oh ja. Wir haben uns heute ein Thema bereitgelegt, das wir auch im Vorgespräch schon kontrovers diskutiert haben und das auch viel Platz für Diskussion offen hält. Wir haben gemerkt, dass wir uns da aus zwei verschiedenen Perspektiven nähern. Es geht um das Thema Testing und vor allem um die Frage, warum wir testen und weniger, wie wir testen. Vielleicht ist das Thema von einem späteren Podcast. Und wir haben gemerkt, dass ich eher so aus der Perspektive des Kunden komme. Also ich muss den Kunden erklären, warum wir Tests schreiben, warum wir da einen Aufwand erzeugen

und warum sich das lohnt am Ende, warum das auch einen Mehrwert für den Kunden hat. Und Kay, du hast eher das Thema, dass du mit den Programmierern ja alltäglich arbeitest und auch in den Code Reviews dann immer wieder Fragen aufkommen. Was muss ich überhaupt testen? Warum muss ich bestimmte Sachen testen? Und eigentlich kommen wir auf die gleichen Schlüsse, aber da gehen wir mal nach und nach vor. Genau, das finde ich ganz spannend, diese unterschiedlichen Ansätze. Das Thema ist tatsächlich aus einem Code Review entstanden. Das nehme ich auch gleich als Aufhänger. Aber ich wollte nochmal sagen, es geht also um automatisierte Tests, die wir dafür benutzen,

um unsere Web-Anwendungen in verschiedenen Hinsichten zu testen. Da gehen wir jetzt drauf ein. Und der Auslöser für dieses Gespräch, das bringe ich dir jetzt einfach mal mit, das war ein Merge-Request von einem Kollegen, den ich mir angeschaut habe und der nur eine einzige Datei geändert hat in diesem Merge-Request und darin wiederum nur eine einzige Sache, und zwar die Hintergrundfarbe von einem Button auf Rot oder sowas. Ich weiß es nicht mehr genau. Und jetzt meine Frage an dich, Felix. Würdest du dafür einen Test schreiben? Ja, das ist ein Thema, über das wir schon hin und wieder mal gesprochen haben.

Und im ersten Moment würde man natürlich denken, und das ist auch, glaube ich, ein Take-away, was wir viel mitgeben, dass wir UI-Sachen eher weniger testen. Jetzt ist das natürlich ein Punkt, wo wahrscheinlich sehr absichtlich eine Farbe geändert wurde und wo die Farbe offensichtlich anders vorher gesetzt wurde. Und dann gehe ich davon aus, dass vielleicht auch eine Kundenanforderung dahinter steht. Und einen Test würde ich deshalb an der Stelle schreiben, um sicherzugehen, dass später nicht jemand anders hingeht und die Farbe wieder ändert, weil er sie vielleicht gar nicht so schön findet oder weil sich irgendjemand was anderes überlegt hat.

Sondern ich würde dann den Test schreiben, um mit dem Test klarzumachen, diese Farbe ist tatsächlich absichtlich hier an dieser Stelle dann eingebaut. Und wenn jemand später das ändern will, dann sieht er dann, wer das gemacht hat und merkt so, ah, da ist vielleicht irgendein Gedanke dahinter gewesen. Jetzt hast du mir schon alle Themen vorweggenommen, Felix. Aber genau so ist es. Und genau das ist auch, was ich dem Kollegen gesagt habe. Die Entscheidung ist nicht so aus einer guten Laune heraus passiert, sondern da hat wohl möglich eine Kundenanforderung hintergesteckt. Da hat sich jemand aus der Projektleitung Gedanken drüber gemacht

und eine Task geschrieben in unserem Projektmanagement-Tool. Dann ist der Kollege hergegangen und hat sich die Aufgabe genommen und überlegt und die Stelle im Code gefunden und geändert und sowas. Also kurzum, es ist richtig viel Zeit in diese offensichtlich banale Änderung geflossen und mit so einem automatisierten Test können wir eben sicherstellen, dass diese Zeit nicht verloren geht, indem in Zukunft das jemand ändert, weil ihm die Farbe nicht gefällt oder sowas. Also der Test ist an dieser Stelle, obwohl es eigentlich so ein trivialer optischer Test ist, Ausdruck für sehr viel mehr dahinter.

Nämlich es hat sich jemand Gedanken gemacht, es hat jemand eine Anforderung gestellt, vielleicht der Kunde, das könnte man dann im Testcase auch erwähnen, was jetzt hier genau die Sache ist. Und wenn jemand in Zukunft das ändert, fliegt einem der Test um die Ohren und man stellt fest, oh, guck mal hier, da war Absicht dahinter. Genau, das ist ein zentraler Punkt, was ich den Kunden auch immer sage, warum wir testen. Wir wollen nämlich eben genau die Kundenwünsche, die Anforderungen vom Kunden bestenfalls irgendwie in Tests abbilden, damit wir hinterher auch sagen können, wir haben eure Wünsche erfüllt und wir können das sogar automatisiert,

testen und wir haben es im Code dokumentiert. Und das ist natürlich ganz wichtig, dass die Anforderungen klar und präzise dann auch umgesetzt sind. Genau, das ist ein anderer Grund, nämlich Kundenwünsche. Und das kann zum einen sein, ein Kunde, der auf die Webseite schaut und feststellt, dass er da gerne einen roten Button hätte. Aber häufig ist ja auch ein Kundenwunsch etwas, was die wiederum benutzen. Also wir haben zum Beispiel auch Anwendungen, für die wir das Backend schreiben, die werden aber von der Software verwendet. Und dann bedeutet Kundenwunsch in diesem Fall eben nicht, der Kunde wünscht sich das gerne,

sondern der hat gegen unsere Anwendung entwickelt und erwartet ein ganz bestimmtes Verhalten, wenn er ganz bestimmtes Inputs sendet. Alles automatisiert und auf Software-Ebene. Und dann ist aus dem Kundenwunsch eine Anforderung geworden, die wir mit so einem Test abdecken können. Nämlich, um mal eine von vielen Vokabeln zu nennen, wir benutzen da CDC-Tests, also Tests, die der Kunde schreibt. Sehr hohe Flughöhe, fast so ein Ende-zu-Ende-Test. Und die stellt aber sicher, dass eben unsere Anwendung so funktioniert, wie der Kunde beziehungsweise seine Software, die er programmiert hat, das erwartet.

Und mit so einem Test können wir das abbilden. Kannst du CDC noch aufdröseln? Gerne. Also das heißt Customer-Driven-Contract-Tests. Das ist mein neues, also ein Lieblingswort. Und das bedeutet im Wesentlichen, der Customer setzt ein Contract, also eine Erwartung, und die bilden wir in Code-Form ab. Haben wir noch weitere Punkte, warum wir testen? Wenn man aus der Sicht des Kunden schaut, dann ist sicherlich auch ein weiterer Aspekt, den wir testen, Verhalten einer Anwendung, die nach außen sichtbar ist. Also das ist ein bisschen abstrakt. Ich versuche es anhand von einem Beispiel zu nehmen, weil so eine Anwendung hat ja direkten Einfluss

häufig auch in die Wirtschaftlichkeit des Kunden. Ich nehme da so ein Beispiel, dass in einer Anwendung irgendeine Art von Statistik generiert wird. Eine Anwendung, die wir geschrieben haben, logischerweise. Und diese Statistik nutzt der Kunde, um wirtschaftliche Entscheidungen zu treffen, um das als Verkaufsargument zu benutzen, um darauf basierend irgendwelche Einkäufe zu tätigen oder weiß ich nicht was. Das heißt, hinter dieser Statistik, die wir erzeugen, steckt ein enormes Potenzial, dass es schief gehen kann. Nämlich einfach, wenn die Berechnung falsch wird. Und dementsprechend legen wir da auch sehr genaues Augenmerk drauf und testen diese Sachen besonders wichtig,

eben weil da so viel schief gehen kann. Genau, das ist dieser Punkt, den vielleicht auch jeder mit automatisierten Tests dann direkt in Verbindung bringt, dass man eben Funktionalität wirklich dauerhaft sicherstellt. Nicht nur in dem Moment, wo ich schreibe, da natürlich auch, sondern dann auch später, wenn sich an der Anwendung in anderen Punkten mal was ändert. Es kann sich zum Beispiel eine Datenbank ändern. Und dann will ich natürlich dauerhaft sicher gehen, dass die Funktionalität auch noch so funktioniert, wie ich sie beabsichtigt habe. Und das Szenario, was du jetzt gerade aufgemacht hast, Kay, ist natürlich eins,

wo es dann gravierende Auswirkungen haben kann, wenn es nicht funktioniert. Und deswegen würde ich sogar so weit gehen, dass es fahrlässig ist, wenn man solche kritischen Sachen da nicht testet. Da stimme ich dir zu. Man muss natürlich jetzt ein bisschen versuchen abzuwägen, weil letzten Endes habe ich ja gerade auch schon im ersten Argument gesagt, eigentlich ist alles, was wir machen, wichtig. Aber trotzdem gibt es dann innerhalb so einer Anwendung doch schon Abläufe oder ich nenne es mal Happy Path, also Wege durch die Anwendung, die vielleicht kritischer sind, in welcher Hinsicht auch immer.

Da würde ich gerne gleich nochmal drauf zu sprechen kommen. Und zwar, was wir nämlich nicht testen. Und da spielt das bestimmt auch nochmal eine Rolle. Genau. Styling nämlich zum Beispiel, wolltest du wahrscheinlich sagen. Und das wollte ich eben auch nur abschließend sagen. Man kann nicht jede einzelne Zeile in der Anwendung testen, mit jeder einzelnen Möglichkeit. Das ist einfach super zeitaufwendig, super intensiv und damit auch kostspielig. Über die Kostspieligkeit und wie man das gegenüber dem Kunden rechtfertigt, reden wir vielleicht gleich noch ein bisschen. Aber deswegen kommt man gar nicht drum rum,

in der Realität Schwerpunkte zu setzen beim Test. Und dafür ist es wichtig zu erkennen, welche Bausteine dieser Anwendung sind denn jetzt gerade entscheidend hier. Ja, und ein Programmteil oder ein Aspekt, den man immer testen muss, ist natürlich alles, was irgendwie mit Sicherheit zu tun hat. Und da reden wir über Authentifizierung zum Beispiel oder um Berechtigung, also welcher Benutzer darf was. Das sind Dinge, wo man das Testen meiner Meinung nach nicht weglassen darf und wo man unbedingt Tests beschreiben muss und wo es auch sehr komfortabel ist, einen Test zu schreiben, weil man automatisiert zum Beispiel bestimmte Berechtigungsstufen durchlaufen kann

und dann hoffentlich die richtigen Ergebnisse bekommt. Das stimmt. Das ist auch noch so ein kleiner Beifang, sag ich mal, nämlich dass Tests häufig das Entwickeln einfacher machen. Das ist eher ein Vorteil für den Entwickler, aber jetzt nicht der Hauptgrund, warum wir das machen. Aber wie du eben sagst, wenn es dann darum geht, ein Autorisierungsszenario zu testen, dann ist das mit automatisierten Tests super schnell gemacht, wo man vielleicht noch anhand von so einem Data Provider ganz schnell verschiedene Szenarien durchgehen kann mit unterschiedlichen Kombinationen von Rollen und Berechtigungen

und Sichtbarkeiten und weiß ich nicht. Bis ich die alle von Hand durchgetestet habe, das dauert ja ewig. Und dann muss ich das auch jedes Mal machen, wenn ich irgendein Update mache, weil wie du sagst, das ist höchst kritisch und es muss sichergestellt werden eigentlich bei jedem Deployment, dass das immer noch so funktioniert, wie es gedacht war. Und da kommt man um automatisierte Tests gar nicht drum herum. Ja, und das ist einer meiner Lieblingspunkte, die ich dann gegenüber den Kunden argumentiere, wenn die sagen, oh, jetzt erzeugt so einen hohen Aufwand mit dem Code und man sagt ja oft, dass man doppelt so viel Code schreibt,

wenn man auch testet. Und dann sage ich eben ganz oft, das ist, du hast jetzt eben ein Beispiel genannt, mit zum Beispiel verschiedenen Berechtigungsstufen durchtesten, dass das sehr aufwendig wäre, das im Browser zu testen. Ich baue jetzt eine Funktionalität, die von bestimmten Benutzern benutzt werden kann, von einer nicht. Jetzt müsste ich in den Browser gehen, mich anmelden mit einem bestimmten Benutzer, müsste den Benutzer vielleicht vorher anlegen, müsste mich wieder abmelden, müsste mich mit einem Administrator zum Beispiel anmelden und könnte so nach und nach die verschiedenen Berechtigungen durchprüfen

mit einem automatisierten Test. Du hast jetzt gerade einen Data Provider angesprochen. Könnte ich das innerhalb von Sekunden und auf Tastendruck abtesten? Eine andere Sache, wo sich das sehr anbietet, sind zum Beispiel APIs. Also wenn ich eine Schnittstelle nach außen habe und die kann natürlich ganz verschiedene Ausprägungen haben und die zu testen kann über dem Browser schon etwas aufwendig sein. Da müsste ich vielleicht ein Postmail benutzen oder ich müsste mir ein Hilfsskript schreiben. Und mit einem automatisierten Test kriege ich das wirklich auf Tastendruck eben sofort das Ergebnis geliefert.

Und ich bin wesentlich effizienter und schneller in meinem Code und habe es gleichzeitig noch getestet, obwohl ich natürlich im ersten Moment mehr Codezeilen schreibe. Das ist, habe ich gerade schon gesagt, so ein positiver Beifang. Nicht unser Hauptargument, gegenüber dem wir das auch den Kunden verkaufen. Aber wenn ich manchmal bei Kollegen so per Pair-Programming zusehe, wie sie eine Änderung im Code machen und sich dann erst fünf Sekunden durch die Anwendung navigieren im Browser, bis sie an der Stelle kommen, die sie testen können, da würde ich ja direkt mir einen kleinen Helper schreiben,

einen kleinen Test, um einfach diesen Aufwand mir abzukürzen. Das ist, wie gesagt, eher nur so ein positiver Beifang. Aber die ganze Entwicklungszeit, man mag ja immer meinen, solche Tests verlangsamen die Entwicklung und es stimmt natürlich auf den ersten Blick, weil man viel mehr Code um die eigentliche Anwendung drum herum schraubt. Aber solche Sachen, vor allem diese Sicherheit, sind dann im Long Run eigentlich sehr viel mehr wert. Und auch für mich als Entwickler, klar, wenn ich jetzt gerade eine Funktion schreibe in meiner Anwendung, dann funktioniert die natürlich. Ich habe parallel den Browser offen in unserem Fall

und teste das und ich mute jetzt meinen Kollegen und Kolleginnen zu, dass die keinen Quatsch abliefern, wenn sie so ein PR schicken. Deswegen ist das Hauptaugenmerk, meiner Einschätzung nach, gar nicht auf den aktuellen Zustand, sondern um wirklich sicherzustellen, dass das in Zukunft auch noch so funktioniert, sodass ich bei künftigen Updates auf den Knopf drücken kann, meine komplette Testbasis läuft einmal durch und erst dann deploye ich auf die Live-Umgebung oder sowas. Genau. Ich habe tatsächlich, wenn ich selbst programmiere, ganz oft den Effekt, dass in dem Moment, wo ich einen Test schreibe

und ich bin selten testdriven unterwegs, also mache selten die Tests vorher, bei APIs und so bietet sich das an, aber bei anderen Sachen bin ich dann eher, ich sage mal in Anführungsstrichen, klassisch unterwegs, dass ich die Tests dann auch nachziehe und dann habe ich den großen Vorteil, dass ich über meinen Code nochmal nachdenken muss und ich habe das sehr oft, dass ich dann wirklich denke, oh, hier habe ich aber noch einen Edge-Case nicht berücksichtigt und das ist ja genau das, worüber man in Tests dann nachdenkt, welche Extreme gibt es, was passiert, wenn ich viele Werte reinbringe und das führte bei mir bisher immer oft dazu,

dass ich wirklich Fehler selbst entdeckt habe im Code und einfach auch einen besseren Pull-Request stellen konnte und du hattest jetzt gesagt, natürlich dieses Klassische, dass man Fehler vermeidet hinten raus und da kommt ja noch ein Effekt rein, den man vielleicht auf den ersten Blick nicht sieht, dass wenn ich jetzt meinen Code schreibe und jetzt einen Fehler habe, dann kann ich ihn relativ schnell beheben, weil ich alles noch im Kopf habe, ich weiß noch, was die Kundenanforderungen waren und meistens sind es dann nur ein paar Minuten, um diesen Fehler zu beheben, wenn ich aber einen Fehler vielleicht erst in einem halben Jahr finde,

dann kostet mich das sehr, sehr viel Zeit, mich da wieder reinzuarbeiten, bestenfalls mache ich das selbst, dann geht es noch etwas schneller, vielleicht macht das aber sogar jemand ganz anderes, ein anderes Team und dann ist es sehr, sehr aufwendig, so einen Fehler zu beheben und dann ist ein Test wesentlich einfacher, schneller, effizienter, als wenn ich das ganze Thema hinterher nochmal aufmache, nicht zu, oder natürlich darf man nicht außer Acht lassen, dass dann vielleicht auch noch eine Verärgerung beim Kunden auftritt oder dass Leute eine Funktionalität nicht nutzen konnten oder nicht so effizient arbeiten konnten.

Ich habe in meinen Notizen das Wort Wertschätzung stehen, Felix, da haben wir im Vorgespräch schon ein bisschen drüber gestritten, aber meiner Meinung nach bilden Tests genau das ab, nämlich Wertschätzung von uns als Auftragnehmer im letzten Endes, also Dienstleister, gegenüber verschiedenen Parteien, also Wertschätzung gegenüber dem Kunden, dass wir seine wirtschaftlichen Aspekte sicherstellen, wirtschaftliche Einflüsse sicherstellen, dass wir seine Kundenwünsche abbilden und solche Sachen, Wertschätzung gegenüber dem Endnutzer durch Authentifizierung und Validierung, also die Nutzerdaten sicherstellen,

aber auch Wertschätzung gegenüber unseren Kollegen, dass eben die Arbeit, die sie jetzt machen, nicht später durch eine Unachtsamkeit wieder revidiert wird. Aber du warst damit nicht so ganz zufrieden, Felix, oder? Ja, mit diesem Begriff der Wertschätzung. Ich finde es aber tatsächlich, so wie du es jetzt erklärt hast oder vielleicht auch im Kontext, den wir aufgemacht haben, nicht mehr so irritierend, wie ich das noch im Vorgespräch fand. Oh, das freut mich ja, wenn sich in so einem Gespräch sowas klärt. Es gibt natürlich ein großes Problem bei dieser ganzen Sache. Ich weiß nicht, ob wir schon bereit sind, darüber zu sprechen

oder ob du noch ein weiteres Argument aufmachen möchtest. Ich wäre noch ganz kurz auf ein Thema eingegangen, was bei uns noch besser getestet werden könnte und wo wir noch nicht so viel machen. Das ist in Richtung Performance. Dass wir nicht nur sicherstellen, dass die Anwendung funktioniert und dass sie sicher ist, sondern dass wir auch dauerhaft sicherstellen können, dass zum Beispiel, du hattest die Statistiken angesprochen, wenn jetzt ganz viele Daten mal gesammelt wurden, dass es dann auch weiterhin noch funktioniert. Das finde ich beim Testen auch ein sehr wichtiges Thema, wo wir aber ganz klar bei uns jetzt in der Firma noch Baustellen haben,

weil wir nicht intensiv mit vielen Daten testen, zumindest bei den allermeisten Kunden nicht. Und deswegen würde ich das gerne hier im Podcast auch nochmal mit aufnehmen, damit wir uns selbst für das Thema nochmal weiter sensibilisieren. Sehr gerne. Ich bin sicher, wir schließen nochmal einen Podcast an, wo wir auch über konkrete Testszenarien sprechen. Das haben wir jetzt umschifft, also wo wir auch mal über Unit-Tests sprechen, über diese Performance-Tests, über die ganzen verschiedenen Stichpunkte, die es da gibt. Für heute ist mir wichtig, dass die Kolleginnen und Kollegen bei ihrer Arbeit vielleicht ein Gefühl dafür bekommen,

worauf sie ein Augenmerk legen müssen. Und das ist, glaube ich, auch schon der große Knackpunkt an dieser Sache, nämlich, dass den Kollegen damit in gewisser Weise die Verantwortung zugesprochen wird,

solche Sachen zu erkennen. Also zu erkennen, was sind denn jetzt besonders wirtschaftlich kritische Aspekte so einer Anwendung. Über so Sicherheitssachen kann man vielleicht noch eine Erfahrung sammeln, aber insgesamt braucht man ein relativ gutes Verständnis von der Anwendung, um entscheiden zu können, was ist denn jetzt so ein kritischer Pfad in irgendeiner Hinsicht, wo es besonderes Augenmerk geben soll. Weil, wie der Kollege aus dem Beispielszenario, der hat das nicht so gesehen, dass er einen Test für eine CSS-Änderung schreiben sollte. Also dann, nachdem wir darüber gesprochen haben, schon.

Aber diese Einstiegssensibilisierung ist, glaube ich, eine Hürde. Und deswegen sprechen wir ja auch heute drüber. Zumal wir uns in dem konkreten Szenario ja sogar selbst widersprechen, weil wir sagen, wir wollen eigentlich UI weniger testen. Also alles, was optisch ist, ist für uns meistens nicht so kritisch. Also wenn der Button mal nicht schön aussieht, hat das normalerweise keine gröberen Folgen für die Anwendung. Deswegen ist das eigentlich ein Thema, wo wir weniger testen. Und in dem konkreten Fall widersprechen wir uns eben selbst und wollen dann doch diese Farbe testen, weil das eben eine ganz spezielle Anforderung vielleicht von dem Kunden war,

die wir hier dann umgesetzt haben. Genau. Und das ist auch die Abbildung von der Semantik, die dahinter steckt. Da ist dann die Farbe nicht nur hübsch anzusehen, sondern bedeutet irgendetwas. Das ist sicherlich auch Aufgabe, wenn wir ein bisschen schon selbstkritisch sind, dass man bei der Aufgabenplanung schon berücksichtigt, was sind denn da jetzt kritische Dinge und vielleicht schon so eine Art Definition of Done mitgibt, anhand deren die Leute wissen, oh, schau mal hier, Statistiken, da muss ich vielleicht besonderes Augenmerk drauflegen. Weil ansonsten, habe ich gerade schon gesagt, bürden wir den Kollegen da sehr viel Eigenverantwortung,

die komplette Anwendung zu verstehen und dann solche Sachen zu beurteilen. Das sind dann so Akzeptanzkriterien, die man vielleicht auch in einen Ticketschall mit reinschreiben kann, in eine Story und dann direkt erkennt, das könnte auch ein Testszenario sein. Und das war ja auch für uns ein Weg. Am Anfang haben wir auch so ein bisschen rumgerudert, so nach dem Motto, ja, ich weiß, man muss Tests schreiben, alle sagen das. Aber so richtig diese Motivation, die wir jetzt heute besprochen haben und daraus abgeleitet, auch so Schwerpunkte, das war bei uns auch ein Prozess, das herauszufinden. Ja, und das dauert ja genau so lange,

bis man selbst einmal gemerkt hat, oh, das hat mir ja richtig was gebracht, das ich hier getestet habe. Und je öfter man das hat und je flüssiger man auch in dem Schreiben von den Tests selbst wird, desto mehr hat man diese Idee davon, warum das sinnvoll sein kann. Das ist ja meine liebste Reaktion, wenn ich irgendwelche Monologe halte, so wie jetzt heute zum Beispiel, und die Kollegen sich das anhören und das dann umsetzen und dann nachher sagen, oh ja, Kay, es hat sich richtig gut angefühlt, das umzusetzen. Weil das bedeutet nämlich, dass die Leute das nicht nur machen, um mich zufriedenzustellen,

sondern wirklich für einen objektiven Mehrwert in der Anwendung. Ja, und man hat aber subjektiv einen besseren Eindruck von seinem Code. Wenn ich einen Code geschrieben habe, wo ich das Gefühl habe, der ist sehr gut getestet, dann gehe ich sehr selbstsicher mit dem auch nach draußen und stelle einen Merge Request und freue mich schon auf das Review, weil ich denke, ah, das ist einfach hochwertiger, qualitativer Code. Ich habe das getestet, da kann nichts schief gehen. Am Ende geht es dann oft, geht es dann oft trotzdem in ein paar Diskussionen im Merge Request natürlich. Aber dieses Confidence-Level ist ein ganz anderes,

wenn man die Anwendung schon mal selbst getestet hat. Das ist natürlich das Traum-Szenario, dass der Entwickler selber dadurch auch ein schöneres Leben hat. Jetzt habe ich mich sehr schwer getan, irgendeine Art von Fazit oder Referenz zu finden für die Leute, die das jetzt hier hören und sich denken, oh, das klingt ja alles ganz großartig, das will ich auch. Weil ich glaube, das einzige Lernmittel, das ich mitgeben kann, ist Erfahrung. Also nicht scheuen, damit mal anzufangen. Es gibt ja Tutorials genug da draußen. Aber so richtig eine Guideline von das sind die Schritt-zu-Schritt-Wege, die man gehen muss,

habe ich nicht so richtig. Hast du da was gefunden? Nee, ich würde mich auch einfach wirklich mehr daran orientieren, die Sachen, die wir jetzt gesagt haben, warum testen wir das, würde ich den Leuten mitgeben. Das ist für mich ganz klar. Wir wollen die Kundenwünsche im Code dokumentieren. Wir wollen die Funktionalität dauerhaft sicherstellen. Wir wollen die Performance garantieren und wir wollen die Sicherheit gewährleisten. Und vielleicht als kleiner Anhaltspunkt, was wir nicht testen, haben wir jetzt gesagt, dass wir in der UI selbst weniger testen, weil das erstens code-technisch schwierig umzusetzen ist

und weil sich auch oft was ändert und weil es meistens business-technisch nicht so wichtig ist. Und was wir auch nicht testen, sind externe Abhängigkeiten, externe Bibliotheken, externe Pakete, weil wir da davon ausgehen, dass die eben da, wo sie entwickelt wurden, dann schon getestet wurden. Und das finde ich eigentlich so ganz greifbar, warum und was wir testen. Sehr wertschätzend alles. Da freue ich mich schon unser Folge-Podcast, wo wir dann wirklich mal einzelne Szenarien und Beispiele aufmachen. Der wird sicher kommen. Ja, bin ich auch sehr gespannt, vor allem wenn du dann Beispiele aus der Praxis mitnimmst.

Kay, ich glaube für heute ist das Thema eigentlich rund geworden und wir können es so abschließen. Ich würde einen Blog noch hinten anhängen, vielleicht machen wir das jetzt auch öfter und zwar ist das ein Feedback-Blog. Wir haben die ersten Folgen jetzt veröffentlicht und haben ein ganz wertvolles, ganz tolles Feedback von ganz unterschiedlichen Leuten bekommen. Auch viele Leute, die technisch zum Beispiel gar nicht versiert sind. Und wir haben natürlich auch heute schon versucht in der Folge viel unterzubringen von dem Feedback. Alles hat nicht geklappt, aber ich sehe den Podcast so ein bisschen

wie so Merge-Request jedes Mal, dass wir den nach außen bringen, dann wieder Feedback bekommen, auch gerne kritisches Feedback oder vielleicht sogar am allerwichtigsten kritisches Feedback und im nächsten Podcast dann die Sachen versuchen zu verbessern, das mitzunehmen, was wir da rausnehmen können. Und ja, so wollen wir uns eigentlich iterativ verbessern. Da geht mir ja nur das Herz auf. Also vielen Dank für das Feedback. Wir haben auch einen offiziellen Feedback-Kanal an dieser Stelle für Leute, die vielleicht auf diesen Podcast stoßen und uns nicht persönlich kennen. Das ist eine E-Mail an podcast.genen-it-systeme.de.

Da freuen wir uns vor allem über kritisches Feedback, aber natürlich auch über ganz viel Lob und Begeisterung. Okay, es hat mir wie jede Woche wieder viel Spaß gemacht und ich freue mich auf die nächste Episode. Ja, ich ersetze schon mal den nächsten Tee auf. Bis dahin.