Transkript
Matthias: [00:00:01.26] Hallo zusammen, wir wünschen euch einen wunderschönen guten Tag!
Alex: [00:00:04.44] Herzlich willkommen bei der Macht der Craft.
Matthias: [00:00:07.95] Heute begleiten dich wie immer, der Matthias
Alex: [00:00:11.02] und der Alex mit dem heutigen Thema TDD Test Driven Development. Der dritte Teil der Miniserie Test gehören auch dazu.
Matthias: [00:00:21.63] Heut wirst du erfahren, was TDD ist und wofür es gut ist. Wir erzählen von den Vorteilen, die TDD mit sich bringt und wollen dir aber auch ein paar Problemchen und Schwierigkeiten erzählen, die man haben könnte und wie man die dann eventuell auch lösen kann.
Alex: [00:00:37.62] Wir meckern über verständnislose Vorgesetzte und nicht agile Organisationen. Aber fassen uns auch an der eigenen Nase.
Matthias: [00:00:45.66] Wir wünschen euch viel Spaß beim Zuhören und hoffen, dass ihr viel dabei lernt.
Off: [00:00:51.84] Die Macht Der Craft arbeitet für dich.
Alex: [00:00:57.44] TDD – man redet überall über TDD. TDD ist eine tolle Sache. Aber bevor wir anfangen zu definieren, was TDD ist oder zu erklären, was TDD ist, möchte ich mal kurz sagen, was TDD nicht ist. Und bei TDD geht es nicht ums Testen, sondern es geht ums ums Entwickeln. Es geht um den Code, die wir generieren. Wir nutzen die Test nur als Hilfe für die Entwicklung. Es geht auch nicht darum, erst eine ganze Menge an Tests zu schreiben und dann den Code zu schreiben, um diese Tests grün zu machen, dass diese Tests funktionieren. Das ist auch nicht der Ziel der TDD und was es auch nicht ist oder worum es auch nicht geht, ist – also es ist nicht das Ziel, so viele Tests zu schreiben wie möglich, sondern nur die Tests zu schreiben, die notwendig sind, um die Implementierung voranzutreiben, die wir machen wollen. Es sind weit verbreitete Missverständnisse. Ich wollte die von vornherein aus dem Weg schaffen. Darum geht es nicht. Aber Matthias, worum geht es dann eigentlich?
Matthias: [00:02:06.84] Also worum geht es bei TDD? Zuerst sollte man vielleicht einfach mal einfach nur mal kurz der Vollständigkeit halber sagen Wofür steht TDD? Das steht für Test driven Development, wie man da vielleicht auch schon ein bisschen raushören kann, gehts da eben tatsächlich, wie Alex, wie du es gerade schon gesagt hast, eher um die begleitende Funktion von den Tests. Also wir nutzen Tests, um den richtigen Code zu schreiben und auch wirklich nur so viel Code, wie notwendig ist, um eben die notwendige Funktionalität umzusetzen. Und das Ganze hat eine gewisse Historie. Also das hat Anfang der 2000er ungefähr angefangen und hat sich so ein bisschen aus dem sogenannten Extreme Programming Ansatz herauskristallisiert und hat seitdem aber auch abseits von der Methode Extreme Programming auch abseits davon deutlich an Bedeutung gewonnen und ist sozusagen eigentlich so in aller Munde heutzutage. Genau. Und das ganze ist eben ein Test first Ansatz. Und das bedeutet letztendlich, dass ich den Test vor der Implementierung schreibe. Also ganz streng genommen ist es so, dass ich keine Zeile produktiven Code schreibe, für die es keinen roten Test gibt.
Alex: [00:03:28.35] Ne super Sache. Wir haben aber in der letzten Folge über die Testpyramide gesprochen und verschiedene Test Typen, die wir in diesem Test Pyramide ansiedeln. Wo siehst du diese TDD Ansatz innerhalb von diese Pyramide oder sind völlig unterschiedliche Sachen.
Matthias: [00:03:46.92] Also ich persönlich würde die eher so im unteren Drittel dieser Pyramide ansetzen. Also ganz klar bei Unit-Tests. Also da – also ich persönlich versuche auf der Unit-Testebene Mikro-Test-Ebene ganz unten in der Pyramide eigentlich ausschließlich nach TDD zu arbeiten, weil es mir persönlich einfach hilft. Man kann aber durchaus auch in die Integrations-Ebene hinein mit diesem Ansatz erfolgreich sein. Ganz oben – also so Richtung End-to-End-Tests wird’s halt irgendwann weniger sinnvoll in meinen Augen, weil diese Tests werden über einen sehr sehr langen Zeitraum rot sein. Und das ist in meinen Augen nicht im Sinne des Erfinders an der Stelle.
Alex: [00:04:33.90] Ich bin auch deine Meinung, also auf jeden Fall. Mikro- und Unit-Tests, kann man TDD nutzen auf dieser Ebene, um die Entwicklung unseres Produkts voranzutreiben. Aber auch eine gewisse Menge an, sagen wir mal low level Integrations Tests kann man damit auch machen. Weiter oben würde ich andere Techniken nutzen, natürlich auch automatisierte Tests. Ja, also tatsächlich. TDD bedeutet, wie ich gesagt habe, nicht alle Tests zu schreiben, die wir uns einfallen, sondern nur die Tests schreiben, die wir brauchen, um alles zu spezifizieren, was wir machen müssen und was unsere Implementierung machen muss. Da fallen auch öfters Begriffe wie z.B. KISS oder YAGNI. Ja, es bedeutet, KISS bedeutet „Keep it simple“ oder „Keep it stupid simple“. YAGNI bedeutet soviel wie „Machs net, du wirst es eh nicht brauchen“. Das sind Prinzipien, die sehr eng mit TDD gekoppelt sind, weil wir setzen dem Fokus nur auf den Code, die wir brauchen, um die Tests, die wir schreiben, grün zu kriegen. Also wir formulieren einen Test, machen den Grün. Dann formuliere mal einen neuen Test, der die Funktionalität, die wir bis jetzt hatten, erweitert in der Richtung, die wir sie haben wollen. Und dann machen wir so schnell wie möglich so einfach wie möglich, ne „Keep it simpel“, so einfach wie möglich. Machen wir dieses Test grün und das wiederholt sich. Aber das ist nicht alles in den TDD Zyklus. Könntest du mal den Zyklus mal kurz beschreiben?
Matthias: [00:06:17.43] Ja, Klar. Wenn man jetzt rein nach dem Lehrbuch geht, ist der relativ einfach aufgebaut. Also der TDD Zyklus besteht im Prinzip aus drei Phasen. Das sind die Phasen „Red“ „Green“ und „Refactor“. Wobei es im Prinzip essentiell ist, dass der erste Schritt ein roter Test ist. Wie auch vorhin schon erwähnt, ich schreibe, wenn ich mich jetzt streng ans Lehrbuch halte, keine Zeile produktiven Code für die es keinen roten Test gibt. Das heißt, des muss der erste Schritt sein. Im zweiten Schritt werde ich diesen Test, der eben rot ist, durch eine zugehörige Implementierung und da ist ganz wichtig, mit so wenig Code wie möglich diesen Test grün zu bekommen. Und wenn ich diesen Test grün habe, dann kommt eben der letzte Schritt und des ist des refaktorieren oder refaktorisieren. Da – immer noch nicht ganz schlüssig, was richtig ist. Und da ist es dann so, dass ich, wenn ich die Sicherheit habe, dass meine Implementierung den Test vorher grün gemacht hat, dann kann ich sehr sicher Änderungen am Code vornehmen, am Bestehenden. Also ich füge da keine Funktionalität mehr hinzu. In diesem Schritt, sondern ich baue bestehenden Code, der meinem vorher roten Test eben grün gemacht hat, so um, dass er schöner wird, besser lesbarer, möglicherweise auch performanter. Also da ist ganz viel möglich. Aber das ganz Wichtige ist. Ich habe vorher im Schritt vorher eben diesen Test grün gemacht und der sollte nach dem Refaktorieren natürlich auch noch grün sein. Und wenn ich diesen Zyklus durchgegangen bin, dann fange ich im Prinzip wieder von vorne an. Also ich schreib dann höchstwahrscheinlich für dieselbe Klasse, eventuell sogar für dieselbe Methode einen weiteren Test, der eben z.B. einen negativ Fall statt einen positiv Fall abtesten soll und geht da den gleichen Zyklus wieder durch.
Alex: [00:08:16.56] Okay, ich versuche zusammenzufassen. TDD-Zyklus Red Green Refactor. Und diese drei Schritten wiederholen sich immer wieder. In der Red Phase fangen wir an, indem wir ein Test schreiben. Dieser Test muss unsere Entwicklung vorantreiben. Also wir testen irgendwas, das wir wissen, das noch nicht implementiert ist, oder noch nicht richtig implementiert ist. Und dieser Test ist natürlich eben rot. Deswegen Rot-Phase, weil eben die Implementierung noch fehlt, oder noch nicht vollständig ist. Dann gehen wir zu Phase Grün. Die Phase Grün besteht darin, den notwendigen Code zu schreiben und zwar so wenig wie möglich, wie du wohl gesagt hast. Um den neuen Test, die wir hinzugefügt haben, grün zu machen. Wichtig, ohne keine der anderen Tests, die schon da sind, kaputt zu machen.
Matthias: [00:09:11.86] Das ist korrekt. Das hatte ich vergessen, da hast du recht.
Alex: [00:09:15.04] Also beim ersten Test. Die er schreiben kann man ja keine kaputt machen, weil es keine gab. Da warst du schon richtig. Aber ab der zweite, dritte 10te, 15te Iteration. Das sind schon andere Tests da und die dürfen wir nicht kaputt machen. Also wir machen der neue Test grün. Aber machen die anderen dabei nicht kaputt. Damit wir die Sicherheit haben, dass alles, was wir bis jetzt implementiert haben, durch ein Test abgedeckt ist. Und dann gibt’s die Refactor-Phase oder die dritte Phase – Refactoring -, in dem wir die Änderungen, die wir schnell gemacht haben, mit dem Minimum am Code, die uns eingefallen ist, produziert haben – dann versuchen, eine bessere Form zu geben. Du hast gesagt, schöner zu machen, das ist ein Begriff, die – ich finde, es trifft, aber es gefällt mir nicht so sehr. Es geht nicht nur um die Schönheit des Codes an sich, weil für schöneren Code werden wir nicht bezahlt, sondern der Kunde interessiert sich überhaupt nicht dafür wie schön unser Code ist aber durchaus diese Refactoring nutzt uns unser Code so vorzubereiten, in Anführungszeichen besser zu machen, damit wir besser arbeiten können, damit es besser warten können, damit andere Kollegen schnell reinkommen und verstehen, was da passiert. Also wie gesagt ganz einfach Red Green Refactor und dann wieder von vorne. Aber warum machen wir das? Was hat das für Vorteile? Was denkst du?
Matthias: [00:10:49.90] Ja, also für mich hat es schon mal den einen ganz klaren Vorteil, dass ich die ganze Zeit weiß, – also ich beweise eigentlich durchgehend, dass der Code, den ich produziere, die Ergebnisse liefert, die ich erwarte. Und das ist für mich schon mal eigentlich der Hauptvorteil. Also ich hab die ganze Zeit, wenn ich die Tests ausführe. Sagen wir mal grün auf schwarz, wenn ich es im Terminal mach, dass das stimmt, was ich mache. Vorausgesetzt natürlich die Tests, die ich schreib stimmen, aber wenn man sich dann wiederum an so KISS-Prinzipien und sowas hält, dann ist das Ganze ja so simpel heruntergebrochen, dass man da zu einem gewissen Grad schon sehr sicher sein kann. Also das ist für mich so der Hauptvorteil. Es gibt aber auch noch andere Vorteile. Es ist zum Beispiel, – das ist auch der Grund, warum ich mir das irgendwann angewöhnt habe so zu arbeiten, ist, dass ich in meinen Jahren, die ich jetzt mittlerweile in der Softwareentwicklung unterwegs bin, es häufig eben erlebt habe, dass nicht nur bei der Sicherheit, sondern eben auch bei Tests sehr gern gespart wird. Also das heißt, wenn am Ende von einem Sprint oder einem Meilenstein oder wie auch immer in ein Projekt entwickelt wird, keine Tests da sind und die Zeit knapp wird, dann sind die Tests das allererste, was gestrichen wird, wahrscheinlich sogar noch vor der Sicherheit.
Matthias: [00:12:13.84] Und wenn ich meine Tests aber immer vorher schreibe, dann kann mir die keiner mehr wegnehmen. Also dann kann mir niemand die Zeit wegnehmen, diese Test zu schreiben. Das ist dann nochmal für mich ein sehr persönlicher wichtiger Grund, weil ich persönlich möchte keinen produktiven Code irgendwo einchecken, der nicht mit Tests abgedeckt ist. Also ich möchte zu jederzeit sagen können die Arbeit, die ich abliefere, die ist zu einem gewissen Grad sicher, dass die funktioniert.
Alex: [00:12:45.66] Ja, Ok.
Matthias: [00:12:45.66] Genau und ein anderer großer Vorteil, den ich dann halt auch noch seh, ist aber im Prinzip dann auch quasi naturbedingt. Wenn man streng nach TDD, – gerade in unten, auf Unit-Test-Ebene streng nach TDD arbeitet, dann ist diese hohe Test Abdeckung, die jetzt nicht das finale Ziel von TDD ist, aber die ist ja quasi da ein Nebenprodukt. Also die fällt schon raus. Und ich rede nicht zwingend von einer hundertprozentigen Abdeckung. Aber man muss wenig extra Aufwand betreiben, um eine hohe Testabdeckung zu haben, wenn man eh in seinem Alltag schon die ganze Zeit so arbeitet.
Alex: [00:13:23.44] Aber das ist irgendwas, was man einfach dazu bekommt. Es ist nicht Ziel des TDDs, des bekommt einfach man dazu, weil durch die Art und Weise, wie man mit TDD arbeitet, – nämlich ich scheib erst den Test und dann den Code der diesen Test grün macht. Es ist schon gegeben eigentlich, wie du gesagt hast, dass die Abdeckung am Ende des Tages sehr hoch sein wird. Ein andere Thema, die auch in Anführungszeichen Abfallprodukt von TDD ist. Es ist nicht das Ziel von TDD, aber es wird uns geschenkt, ist das Sicherheitsnetz, d. h. dadurch, dass wir all diese Tests geschrieben haben und dass wir sie automatisch und oft laufen lassen, haben wir ein Sicherheitsnetz, die uns hinweist, wenn wir durch irgendeine Änderung irgendwo eine Verhaltensänderung hinzugefügt haben, die nicht passt mit des, was wir vorher – ja – definiert hatten in unsere Tests. Deswegen haben wir diese, diese geschenkte Sicherheitsnetz, was dazu führt, dass wir viele Fehler früher erkennen können. Wir finden sie sofort, weil diese Tests, diese Sicherheitsnetz uns sofort aufmerksam darauf macht, dass wir irgendetwas falsch gemacht haben. Also können wir es gleich korrigieren. Je früher wir ein Fehler finden, desto billiger ist, desto günstiger ist den zu beheben. Und das ist auch eine der Sachen, die wir mit TDD meiner Meinung nach dazu bekommen. Es wird auch nur implementiert das, was wir getestet haben, da wir keinen Code schreiben, ohne dass es ein Test gibt. Gibt es keinen Code, die keinen Test hat.
Matthias: [00:15:01.57] Und das finde ich ist der, ist die, wie soll man sagen – der große Charme dieser Methode einfach. Da fällt so viel als, wie du es genannt hast Nebenprodukt oder Abfallprodukt eigentlich ab, was uns aber halt eigentlich Vorteile bringt und keine Nachteile. Genau was man halt sonst noch erwähnen kann, ist häufiges Gegenargument gegen TDD. Was in meinen Augen aber in erster Linie daran, – an der fehlenden Übung und oder Routine auch fehlenden Routine liegt, ist, dass immer gesagt wird, man wird langsamer. Also Dinge dauern länger. Also ich hab schon häufig gehört, hat bei euch dann doppelt so lange, wenn ich Test für schreiben soll. Und ja, das halte ich persönlich eben tatsächlich für ein Missverständnis. Weil ich habe letztens irgendwo ich glaube, es war auf Twitter einen interessanten Gedanken gelesen, dass eigentlich der Moment, wo du den Test formulierst, eigentlich gleichzusetzen ist mit der Phase, wo man, wenn man einfach das Implementieren anfangen würde, eben überlegt, wie man das jetzt implementiert. Letztendlich. Ich gehe trotzdem nur im Kopf den Sachverhalt durch
Alex: [00:16:12.82] Und auch wenn es etwas länger dauern täte, was es auch tut am Anfang. Aber sagen wir mal für die Implementierung brauche ich eine Stunde. Wenn du sagst, es dauert doppelt so viel, dann dauert es zwei Stunden anstatt eine Stunde und ich spare mir 10 Stunden Debugging danach, wenn ich einen Fehler finde. Aber ich finde es auch lohnt sich die zwei Stunden zu investieren, um 10 zu sparen.
Matthias: [00:16:34.51] Ne absolute also wie gesagt, ich würde da eh es eher als Missverständnis deklarieren. Und es kommt halt eben häufig auch von Kollegen, die einfach eh ungern nur Tests schreiben. Also das ist ja mehr so eine Abwehrhaltung einfach bzw. die Befürchtung, dass man mit seinem Vorgesetzten irgendwie Probleme kriegt oder sonst irgendwas.
Alex: [00:16:56.26] Bevor wir auf den Problemchen und so kommen, würde ich noch ein Thema, die für mich wichtig ist, auch bezüglich dem Vorteil von TDD. Eine der Sachen, die man als erstes lernen muss, wenn man TDD macht, ist sogenanntes Baby Steps zu verwenden. Also immer in sehr kleinen Schritten die Implementierung voranzutreiben. Das ist wichtig. Weil wir so einfachere Tests schreiben können die klein klein immer die Funktionalität der Anwendungen erweitern. Und wenn man sich das gewöhnt hat, ist man in der Lage. Wenn man es nicht braucht, kann man ja große Schritte, größere Implementierungs-Teile uns vornehmen auf einmal. Aber wenn wir dran gewöhnt sind, diese Baby-Steps zu verwenden und wir merken „Uppsala, ich hab mir jetzt zu viel auf einmal genommen“, dann fällt uns relativ leicht, diese größere Brocken in Teilen abzutrennen, sodass wir deutlich schneller vorankommen, weil wir nicht eine halbe Stunde ein roten Test haben, die nicht funktioniert, sondern nur 3 mal 5 Minuten. Mit diese 3 5 Minuten haben wir die gleiche Implementation auf die Reihe gekriegt. Nur dass anstatt eins in groß in drei unterschiedliche Teilen aufgeteilt haben. Und diese Babys Steps, – wenn nötig tun zu können -, ist irgendwas, das man durch die Übung mit TDD relativ leicht auf die Reihe kriegt. Aber gut, TDD ist nicht das sogenannte Silver-Bullet, nicht alles an TDD ist schön. TDD löst nicht alle Probleme und wir wollen auch nicht leugnen, dass es der eine oder andere Problemchen damit gibt.
Matthias: [00:18:37.25] Ja, also ich kann mal so ein bisschen aus meiner Erfahrung erzählen, was ich immer wieder mitbekomm, was für Probleme Leute mit Tests haben bzw. welches Problem sie in erster Linie haben, damit anzufangen. Weil, ich kriege immer wieder mit, das, also das kann ich auch aus eigener Erfahrung tatsächlich sagen, dass das am Anfang nicht leicht ist, sich davon zu lösen, einfach die Implementierung loszumachen, runter zu schreiben. Und mit der Zeit finde ich, ist es für mich um einiges leichter geworden, weil ich mir irgendwann einfach mal vor Augen geführt habe, was ist denn eigentlich die Herausforderung daran, diesen ersten Test zu schreiben? Also sagen wir mal, ich muss jetzt eine neue Klasse implementieren. Und was hindert mich daran, jetzt für diese Klasse einen Test zu schreiben? Wenn man da mal ein bisschen drüber nachdenkt, muss ich ja in erster Linie, – also sagen wir mal ich habe jetzt eine Klasse, die soll irgendeinen Eingabe-String eine Methode Entschuldigung Methode, die soll irgendein Eingabe String irgendwie transformieren, irgendwas dranhängen und wieder zurückgeben. Und wenn ich die jetzt testen will, dann brauche ich für meinen Tests eigentlich nur drei Sachen. Ich muss mich, – muss mir darüber im Klaren sein „Was will ich in meine Methode hinein geben?“ „Wie soll diese Methode heißen“, die ich da aufrufen will? „Und was soll diese Methode zurückliefern“? Und das sind eigentlich die drei elementaren Teile, die ich brauche, um einen Test für diese Methode formulieren zu können.
Matthias: [00:20:11.37] Und das kann ich jetzt z.B. auch mal einfach an einem Beispiel erläutern. Wenn ich jetzt diesen Red Green Refactor Zyklus für eine komplett neue Klasse durchgehen würde, dann würde ich in einem ersten Schritt würde ich eine Testklasse erstellen. Also das ist im Prinzip eine separate Klasse, die nur dafür da ist, die Tests zu beinhalten für die Klasse, die jetzt gerade noch nicht existiert. Und wenn ich die erstellt habe, dann kann ich in dem Moment einen ersten Test da drinnen schreiben, indem ich eigentlich nichts anderes mache, als meine neue, noch nicht existierende Klasse zu instanziieren. Das kann nicht funktionieren, weil es existiert ja noch nicht. Das heißt, ich bin in dem Moment, bin ich in meinem Red State, dann ist mein Test rot und dann kann ich hergehen und eben die Klasse, die ich testen möchte, dann überhaupt erst mal erstellen. Also in Form einer Datei, in der die mit der richtigen Syntax je nach Programmiersprache, in der ich mich grad befinde, dann eben die notwendigen Schlüsselwörter. Und wenn diese Klasse da ist und wenn die erfolgreiche in meine Testklasse importiert werden kann, dann kann ich den Test erneut ausführen und der Test wird grün werden. Dann hätte ich meinen ersten Red Green Reaktor Zyklus fertig. Soweit okay?
Alex: [00:21:34.41] Ja, obwohl du nicht refactort hast. Aber okay.
Matthias: [00:21:37.47] Ja gut jetzt in dem Falle. Stimmt ja. Stimmt, da hast du recht. Refactor. Okay, wir können wir refaktorieren und die Klasse umbenennen oder sowas.
Alex: [00:21:47.61] Na, der Refactor-Schritt muss man nicht zwingend nach jedem Test machen.
Matthias: [00:21:52.76] Ja.
Alex: [00:21:52.76] Es ist auch für mich völlig okay, drei vier Tests zu schreiben, ohne Refactoring zu machen. Und erst, wenn du siehst, dass irgendwas in Anführungszeichen anfängt zu stinken oder du eine Vorstellung kannst: Okay, das was ich jetzt alles habe, konnte ich schöner oder besser einfach machen, dann lohnt sich ein Refektoring zu machen, weil da Refactoring steht, bedeutet nicht, dass ich in jedes Schritt irgendetwas refactoren muss. Ich muss mir aber zumindest Gedanken machen, ob ich irgendetwas refactoren sollte, zu dem Zeitpunkt.
Matthias: [00:22:22.23] Also genau. Und wenn ich was mit refactoren will, dann muss vorher der alle Tests grün sein. Sowas kann man sagen. Okay, aber wir sind uns einig, das wäre eine neue Klasse, erstellt im TDD Kontext, weil wir uns wirklich streng nach Lehrbuch machen.
Alex: [00:22:39.82] Ja, aber die Klasse tut noch nichts.
Matthias: [00:22:42.27] Richtig, die tut noch nichts. Deswegen gehen wir jetzt einen Schritt weiter und wollen da jetzt eine Methode implementieren. Und wie ich persönlich jetzt da dabei immer vorgehe, ist im Prinzip. Also wir haben jetzt eine leere Klasse, die hat nur einen Namen. Nichts weiter. Und wir haben einen Test. Der hat einen Test, indem wir einfach nur diese Klasse instanziiert und getestet, dass das funktioniert. Und in dem nächsten Schritt hab ich ja jetzt irgendeine Anforderung. Und deswegen wollen wir jetzt natürlich im nächsten Schritt wollen wir diese ganze Klasse um eine Methode erweitern. Und des können wir jetzt auch per TDD machen. Und zwar sagen wir einfach, wir wollen eine Methode schreiben, der wir einen Namen einer Person reingeben und zurück bekommen wir einen String, der im Prinzip zum Beispiel sagt „Hello Matthias“, wenn ich meinen Namen mit reingeb. Also soll uns einfach grüßen. So, und in meinem Test muss ich mir jetzt eigentlich nur überlegen: Was brauche ich, dass ich in meine Methode reingeben will, die ich testen möchte? Wie soll diese Methode heißen und welche Rückgabe erwarte ich? Diese drei Dinge kann ich jetzt anhand von dem Beispiel das ich grad genannt hab relativ leicht benennen. Reingeben werden wir nen String, nämlich den Namen einer Person in meinem Beispiel jetzt „Matthias“. Die Methode schlage ich jetzt einfach mal den Namen „greeting“ vor. Und als Rückgabe erwarte ich einen String, der aus den Worten „Hello“ und dem Parameter den Namen, den ich reingegeben habe, besteht. Und mit diesen drei Informationen kann ich sehr klar einen Test formulieren, ohne eine Zeile Code geschrieben zu haben. Ja, genau. Und das kann ich dann, wenn ich diesen Test geschrieben habe, das also jetzt das im Detail, Zeile für Zeile runter zu erzählen ist wahrscheinlich Blödsinn. Aber ich glaube, man kann es sich vorstellen. Wenn ich dann die Implementierung dazu geschrieben hab und der Test grün ist, dann sind ma halt wieder an dem Punkt, wo man sich dort anschauen kann, „kann ich aus dem Code noch irgendetwas refaktorieren?“ Also kann ich es lesbarer machen in irgendeiner Weise oder anderweitig die Qualität verbessern. Und so würde ich jetzt mal ganz simpel sagen, wie man vielleicht relativ leicht an so einen ersten Test auch ran gehen kann.
Alex: [00:25:09.96] Okay, kein schlechten Beispiel. Das Thema „Wie fange ich an?“ Ok, das ist ein Thema, wo man durchaus Schwierigkeiten haben kann am Anfang. Du hast ein gutes Beispiel genannt. Weitere Missverständnis, dass es öfters gibt oder es sich mal gehört hab, ist, dass wenn ich TDD mache, ich keine andere Tests machen brauch! – Und das ist einfach nicht wahr. TDD ersetzt nicht alle andere Tests. Dass wir viele grüne Tests haben, die wir mit TDD oder die wir durch TDD entwickelt haben. Bedeutet nicht, dass das alles funktioniert, wenn das wir in diesen Prozeß der Entwicklung, was wir mit Tests abgedeckt haben, das tut, was wir uns vorgestellt haben, das es tun soll. Soweit so gut. Aber das ändert nichts an der Tatsache, dass wir größere Integrations Tests eventuell mit Cucumber oder andere Methoden, dass es End-to-End Tests notwendig sind, das auch manuelle Tests eine Rolle spielen und wir sie nicht einfach weglassen können, weil die wichtige und notwendige Informationen für die Entwicklung mitbringen. Ein andere Problem, die wir öfters haben, – obwohl ich weiß, dass wir Entwickler alle gut sind -, sind wir leider nicht perfekt. Nicht immer. Meistens nur. Und ab und zu haben wir halt eine gewisse Betriebsblindheit oder verstehen wir nicht richtig, was irgendein Kunde braucht oder was irgendein Requirement bedeutet, die wir implementieren müssen und implementieren es nicht so, wie es eigentlich gedacht war. Natürlich sind alle unsere Tests grün, weil wir die Anwendung oder das Programm tut genau das, was wir programmiert haben. Was wir machen wollten. Nur das, was wir machen wollten, ist eigentlich nicht das, was wir hätten machen sollen. Weil wir es einfach missverstanden haben zum Beispiel. Und da sind andere Tests, andere Tester, manuelle Tests oder Integrations-Tests auf anderer Ebene, die nicht mit dem TDD Zyklus zu tun haben auch eine Hilfe, um diese Blindheit oder Missverständnisse aufzudecken. Ein anderes Problem und das stimmt tatsächlich. Es ist aber am Ende des Tages für mich kein Problem. Nämlich Wir haben mehr Code. Wir haben nicht nur den produktiven Code, sondern haben auch den Code, die wir für die Tests brauchen. Und es ist mehr Code, als wenn wir keine Test haben, natürlicherweise. Das bedeutet, dass bei der Entwicklung wir mehr Code produzieren müssen. Und auch wenn wir Änderungen oder Erweiterungen an dem Code machen müssen, müssen wir nicht nur den Code schreiben, sondern den Code, die neue Tests bzw. in die andere Reihenfolge, erst die neue Test, dann der neue Code, neue Test und neue Code, neue Test neue Code um in den TDD Zyklus zu bleiben, Refactoring da, wo es notwendig ist. Und gegebenenfalls muss man Tests anpassen, die wir vorher geschrieben hatten, die grün waren, aber die durch diese neue Funktionalität, die das Verhalten meine Anwendung verändert, jetzt nicht mehr funktionieren. Also es gibt ein gewisse Zusatzaufwand. Ja, finde ich aber nicht schlecht in dem Sinne, dass all diese Tests, die ich habe, mir klar und deutlich sagen „Okay, du hast jetzt eine neue Funktionalität hinzugefügt mit dem zugehörigen Test, dadurch muss aber auch noch an Stelle A oder Stelle B was anpassen, weil dein Verhalten sich geändert hat und jetzt deine Funktionen in A und B nicht mehr sich so verhalten wie vorher.“ Und das macht klar und deutlich, wie ich vorher gesagt habe Dieses Sicherheitsnetz mach mir klar und deutlich, ich muss da noch was machen.
Matthias: [00:28:50.99] Aber sei mal dahingestellt. Ich gebe dir recht, dass es letztendlich ist es ein gewisser Zusatzaufwand, den ich in meiner täglichen Arbeit habe. Aber auf der anderen Seite würde ich argumentieren, dass ich gerade im späteren Verlauf von dem Projekt, also wenn wir jetzt von dem Projekt reden, das seit zwei Jahren läuft und von X Entwicklern mit neuen Features bestückt wird, wird in einer Codebasis, die streng mit TDD entwickelt wird es trotzdem deutlich schneller gehen, neue Funktionalitäten hinzuzufügen
Alex: [00:29:25.40] Und vor allem auch mit weniger Fehler.
Matthias: [00:29:28.01] Genau.
Alex: [00:29:28.76] Weil Nebeneffekte, die ich verursache, ohne es zu merken, sofort durch das Sicherheitsnetz entdeckt werden.
Matthias: [00:29:35.96] Genau. Oder eben halt dann spätestens auf Integrations Ebene oder so. Aber wenn ich jetzt eine Codebasis habe, die wirklich über keinerlei Tests verfügt, das ist halt das wirklich gegenteilige Extrem, dann bin ich halt permanent eigentlich nur im Blindflug.
Alex: [00:29:51.01] Eine der Probleme, die ich sehr oft höre. „Ja, aber wenn ich mein Chef sage, dass ich jetzt doppelt so lang brauche, weil ich Tests schreiben will oder weil ich TDD machen will. Er sagt mir, – der zeigt mir einen Vogel, der sagt, ob ich einen Knall habe. Ich kriege das nicht durch, also bei – meine Vorgesetzte hindern mich daran, TDD zu machen“, so in den Dreh, ne. Und obwohl es solche Menschen gibt, möchte ich trotzdem eine Lanze für den Vorgesetzten hier brechen, das ist nicht immer der Fall. Und wenn man ihm deutlich macht, dass das Vorteile hat, es gibt viele, die sich auch drauf einlassen. Aber nichtsdestotrotz gibt es diejenigen, die es nicht tun. Wie würdest du mit denen so eine Situation umgehen?
Matthias: [00:30:35.55] Ich hab mir im Laufe der Zeit tatsächlich angewöhnt, da gar nicht groß, wie soll man sagen, zu fragen, sondern ich sehe tatsächlich für meinen Beruf sehe ich es als essenziell an, dass ich mein Zeug ordentlich mache. Und da gehören für mich Tests dazu und wo ich mit mir drüber diskutieren lasse, ob das dann vor allem mit anderen Entwicklern. Das hat man ja auch schon, ob es vorher oder nachher oder waren auch immer die Tests schreiben. Darüber finde ich, da kann man noch diskutieren. Aber wenn man also ich mach die Tests dann letztendlich einfach. Also ganz kurz gesagt besser um Vergebung fragen als um Erlaubnis an der Stelle. Und wie gesagt deswegen hab ich mir für mich einfach angewöhnt, die Tests einfach als Teil der Aufgabe zu sehen. Also es werden auch keine extra Tickets von mir für Tests angelegt oder extra Issues oder wie man es auch nennen will extra Aufgaben, sondern die Tests schreiben gehört zu der Aufgabe das Feature zu implementieren Punkt aus. Das gehört zusammen.
Alex: [00:31:39.42] Also jetzt völlig unabhängig ob TDD oder nicht. Dass wir Tests brauchen und dass wir Test schreiben sollen, ist keine Verhandlungsmasse. Es gehört dazu.
Matthias: [00:31:49.41] Ich hab dazu mal einen ganz guten Vergleich gehört und hab das tatsächlich auch schon mal einem meiner Vorgesetzten vor Jahren so gesagt. Und zwar, wenn ich jetzt mal in ein Krankenhaus eingeliefert werden würde. Operation steht bevor. Oder, bzw. nee, anders ich wäre der Arzt so und ich müsste operieren und der Patient würde zu mir sagen „Ja, also ich hab’s aweng eilig. Das mit dem Händewaschen, das können wir uns sparen heute“. Würde ich als Arzt dann, weil meinen Patient das sagt aufs Händewaschen verzichten. Hoffentlich nicht, sondern ich wüsste es ist notwendig, es gehört dazu und ich würd’s machen. Und genauso hab ich das auch schon mal von einem Vorgesetzten argumentiert und er hat es tatsächlich auch danach verstanden. Also das ist für mich einfach etwas, Tests gehören dazu und ja, genau wie gesagt, das jetzt, ob davor oder danach. Ich meine, wir reden jetzt heut über TDD. Deswegen in erster Linie mal davor. Ja, einfach machen. Tatsächlich ist mein größter Tipp. Das Problem ist dann halt häufig tatsächlich, wenn man vorher keine Erfahrungen damit gemacht hat. Also wenn das wirklich die ersten Schritte sind, die man geht. Des in einem laufenden Projekt zu machen ist halt unfassbar schwierig und da glaube ich, kommt man tatsächlich auch in Zeitprobleme, aber wenn die Technologien da sind, wenn man sich ein bisschen mit Testen sicher fühlt und man ungefähr weiß, was man macht, dann hält sich dieses Problem in Grenzen.
Alex: [00:33:24.33] Ich sehe keinen Grund, warum es zu einem Problem werden musste, wenn wir es nicht zu ein Problem machen.
Matthias: [00:33:30.81] Auch da nochmal. Vorgesetzte sind ja auch Menschen, mit denen kann man im Normalfall argumentieren und es muss jetzt auch nicht unbedingt das Arzt-Gleichniss sein. Es gibt auch andere Argumente, mit denen man Leute überzeugen kann, wie z.B. eben Qualität, Wartbarkeit, Erweiterbarkeit, weil das sind alles Sachen, die sind ja auch im Sinne des Vorgesetzten
Alex: [00:33:53.04] Auch das Thema kosten.
Matthias: [00:33:54.45] Ja genau.
Alex: [00:33:55.38] Wenn ich jetzt eine Stunde mehr einsetzen muss, damit ich später 2, 4, 8 Stunden spare, wenn ich Fehler beheben muss oder neue Funktionalität hinzufügen will. Das ist auch ein Argument, die meiner Meinung nach zählt.
Matthias: [00:34:11.19] Genau. Und ich glaube auch tatsächlich nicht, dass das in den meisten Fällen zumindest keine Bösartigkeit ist, sondern tatsächlich einfach vielleicht ein Ja, es ist einfach nicht realisieren, dass das halt wirklich dazu führt, dass auch in 2 Jahren noch mit dem selben Zeitaufwand ein neues Feature hinzugefügt werden kann, wie nach zwei Monate nach Projektstart, wenn halt noch kein Code da ist und des runter hacken halt noch super geht. Aber nach 2 Jahren, wenn der Code eben dann entsprechend gewachsen ist, dann kriege ich da halt unfassbare Probleme, da neue Funktionalität rein zu kriegen. Und dann wundert sich der Vorgesetzte auf einmal „Warum geht das jetzt alles so langsam?“ „Warum muss ich gefühlt jeden Monat neue Entwickler einstellen, um ansatzweise denselben Output zu bekommen?“ und ja und wie gesagt auch da -. Für sowas sind glaub ich viele offen, wenn man es ihnen erklären kann. Und es gibt da draußen glaub ich auch zahlreiche Visualisierungen von solchen Problematiken, wo Kurven dann auf einmal ins Unendliche schießen, was Aufwand und Output und sowas angeht. Also da findet man glaub ich für Argumentationen schon einiges mittlerweile im Internet da draußen.
Alex: [00:35:23.71] Aber das ist nicht das einzige Problem. Also Vorgesetzte und nicht agile Organisationen, Command- und Control-Strukturen sind ein Problem, aber es ist nicht das einzige Problem. Wir selber sind manchmal das Problem. Es gibt Kollegen und Kolleginnen, die nichts davon halten. Die meinen, das haben wir noch nie so gemacht. Warum sollten wir das jetzt ändern? Des war noch nie notwendig. Was willst du jetzt? Es dauert viel zu lang. Und so weiter und so fort. Wie können wir da argumentieren, um um diese Kolleginnen ins Boot zu holen, so dass sie sich auch wohl dabei fühlen und es nicht als eine Zeitverschwendung erachten.
Matthias: [00:36:06.10] Also ich würde zuerst einmal versuchen herauszufinden, welches Problem Sie tatsächlich damit haben. Häufig ist, glaub ich, das Problem tatsächlich genau diese fehlende Sicherheit also bzw. die Sicherheit, dass sie unsicher sein werden. Wenn man damit anfängt. Wir haben ja vorhin drüber geredet, dass es gerade sowas wie den ersten Test zu schreiben vor der Implementierung. Wenn man das das erste mal macht, kann es gut sein, dass man da sitzt und erstmal keine Ahnung hat, wie man anfangen soll. Kann passieren. Und ich glaube davor haben sehr viele Angst. Vor allem wenn das dann nicht alleine ist, sondern wenn du dann auch noch in einer Gruppe bist. Also wenn du es tust z.B. mit deinen Kollegen einfach mal üben willst oder so, kann das glaube ich schon ein Killer sein von so einer Session. Wenn sich jemand gleich am Anfang beim ersten Test unwohl fühlt und sich unfähig fühlt und wenn du dann,- je erfahrener, dann die Entwickler werden. Also sagen wir mal 10 Jahre Erfahrung, 15 Jahre, 20 Jahre. Je mehr des werden, desto, – wie soll man sagen -, desto schwieriger kann es für jemanden sein, über diesen Schatten zu springen und es sich einfach mal drauf einzulassen. Und deswegen wäre es so ja, meine Herangehensweise wäre dann eher tatsächlich versuchen, es aweng spielerischer zu machen. Also wir hatten es in einer unserer ersten Folgen hier mit Code-Retreat und Katas und solche Geschichten und sowas wäre dann wahrscheinlich ein ganz guter Einstiegspunkt, um das mit Entwickler-Kollegen, Kolleginnen mal einfach auszuprobieren.
Alex: [00:37:41.66] Und was ich auch
Matthias: [00:37:43.45] Die Angst nehmen, weil das ist glaube ich so das Hauptproblem,
Alex: [00:37:46.90] Was ich auch schon mal gemacht habe. Ich sag mal so schön mit nem Beispiel vorangehen und einfach Kolleginnen um Hilfe fragen. Stell dir vor, ich muss irgendeinen Issue implementieren und ich arbeite mit TDD und ich sag dir Matthias, kannst du mir helfen? Du bist jetzt der volle TDD Gegner oder du benutzt TDD nicht oder du kennst es nicht und ich versuche da mit dir in ein Gespräch zu kommen, wenn du mir hilfst, so dass du mir sagst, du musst das und das machen. Ich würde versuchen, da einen Test zu schreiben mit dir, sodass wir die Implementierung dann so treiben. Ok,du willst, dass wir das machen. Okay, lass uns mal kurz ein Beispiel, – nenn wir es nicht Test, nenn wir es einfach Beispiel – schreiben, was ich erwarte, wenn ich das reinkomme. Und wenn du wie du gesagt hast, ich weiß, wie die Funktion heißt. Ich weiß, was ich reinschieben, ich weiß, was ich erwarte. Es ist schreibe ich irgendwann um, dann sage ich und hier erwarte ich, dass das und das gekommen ist. Hab ich das richtig verstanden? Wenn du sagst ja, zack. Schreibe „@Test“, oben drauf und haben ein Test.
Matthias: [00:38:53.74] Ja. Das erfordert allerdings, dass du dich jetzt halt schon relativ gut mit diesen Methoden auskennst.
Alex: [00:39:02.47] Ja gut, natürlich.
Matthias: [00:39:03.37] Dann kannst du das so machen, ja. Aber ich glaube, wenn man jetzt irgendwo in einem Entwicklerteams komplett neue reinbringen muss, will und man selber keine große Erfahrung hat, dann bieten sich wahrscheinlich trotzdem die Lern Formate erst mal besser an..
Alex: [00:39:19.38] Durchaus.
Matthias: [00:39:20.17] Aber ja klar. Also ich meine es ist eh von Vorteil, wenn ich das jemand anders zeigen will, oder dafür werben will, dass man es benutzt. Dann macht es natürlich Sinn, wenn ich selber mich damit schon mal in irgendeiner Form auseinandergesetzt habe und ungefähr weiß, wie ich vorgehen muss, was ich machen muss. Genau, weil was halt nicht hilft, Gegner zu überzeugen von so einem Ansatz ist halt dann rum zu stöpseln und das net ans Laufen zu bekommen und permanent irgendwelche anderen Probleme zu haben, weil dann bekräftigt man im Prinzip die Gegenargumente nur. Es ist ja nur Zeitverschwendung. Und was machen wir hier eigentlich? Und dieses und jenes. Also da muss man dann ein bisschen aufpassen. Ausreichend gemeckert.
Alex: [00:40:07.59] Genau, hör ma auf zu meckern und ein Ansatz, die sich für mich bewährt hat, ist, die Tests auf eine gewisse Art und Weise zu strukturieren, sodass alles Tests, obwohl die völlig unterschiedliche Sachen machen, ungefähr die gleiche Struktur haben. Und das ist dieses sogenannte Triple A System. „AAA – Arrange – Act – Assert“. Kannst du uns erzählen, was das ist und wie das aussieht?
Matthias: [00:40:34.05] Ja, kann ich gern machen. Also im Prinzip nutze ich diese drei Begriffe Arrange, Act und Assert, um meinen Test ein bisschen zu strukturieren. Was so Tests häufig eben mitbringen, ist der Umstand ich muss Daten vorbereiten. Also wir hatten es ja vorhin mit dem Beispiel, dass ich wissen muss, was ich reingeben will in meine Methode, die ich gerade teste. Und das sind häufig nicht Strings, wie wir es vorhin hatten, sondern halt Objekte, größere Listen oder oder oder. Diese ganzen Vorbereitungen fallen unter das erste A, nämlich dass Arrange
Alex: [00:41:12.97] Arrange, wären die ganze Vorbereitungen, die ich machen muss, um den State so zu kriegen, dass ich meine Aufrufe tätigen kann, sozusagen.
Matthias: [00:41:22.92] Genau. Und wir machen das. Also wir machen das klassischerweise bei uns in den Tests mit Kommentaren. Also wir haben in jedem unserer Tests sind bis zu drei Kommentare im Act Arrange und Assert. Und wenn wir das alles jetzt vorbereitet haben, dann würde im nächsten Teil der Act-Teil kommen. Das ist eigentlich nur der Aufruf der zu testenden Methode. Also meistens eine Zeile und im Assert-Teil. Da nehmen wir jetzt dann die Rückgabe von der Methode, die wir aufgerufen haben und vergleichen die mit den Erwartungswerten. Und das ist dann der Assert-Teil. Und was halt eben auch klar sein muss, ist diese drei As, die existieren in jedem Test, also nicht einmal pro Test-Klasse oder sowas, sondern in jedem Test. Weil die sollen ja auch unabhängig voneinander sein, dieser Tests. Dann Hab ich einen Vorbereitungs-Schritt, einen Ausführungs-Schritt und einen Assertion-Schritt.
Alex: [00:42:23.24] Ich würde zum Abschluss noch ein paar Sachen erwähnen, was wir mit TDD, – ja -, auf die wir in TDD achten müssen, aufpassen müssen. Wir sind ein paar sogenannte Anti Patterns. Sachen, die wir überhaupt, man micht machen soll sich z.B. Tests aufbauen, die voneinander abhängig sind, formulieren wir es positiv. Alle Tests sollen voneinander unabhängig sein. Das heißt, es ist egal, in welcher Reihenfolge ich die Tests ausführe, weil öfters mal durch die Automatisierung habe ich keinen Einfluss, in welcher Reihenfolge die Tests ausgeführt werden. Öfters mal werden auch mehrere Tests parallel ausgeführt. Also keine Abhängigkeiten zwischen Test. Jede Test für sich unabhängig und funktioniert völlig unabhängig von den anderen Tests. Deswegen diese wichtige Arrange-Bereich, wo wir in jeden Test vorbereiten das was wir brauchen, damit der Test lauft
Matthias: [00:43:21.41] Genau und wenn ich immer das gleiche machen muss also für jeden Test in einer Klasse immer die gleiche Vorbereitung hab, dann kann ich das nur noch in der Methode auslagern. Aber es muss trotzdem vor jedem Test passieren.
Alex: [00:43:34.99] Genau. Ganz wichtig, die Tests müssen schnell laufen. Da sind wir auch genauso wie bei der Pyramide ganz unten bei Unit- und Micro Test haben wir gesagt, das muss ins Ruckzuck Ergebnisse da sein. Es ist bei TDD genauso genauso wichtig, weil ich die Tests dauernd ausführe. Ich schreib ein Test, führe die Tests aus. Das ist rot. Mach die Implementierung führe die Tests aus. Es ist grün. Wenn jedes Mal euch die Tests ausführe 10 Minuten warten muss. Es ist nicht machbar.
Matthias: [00:44:09.07] ja dann, In so einem Fall wäre ich wahrscheinlich sogar selbst bei der Argumentation auf der Gegenseite. Wenn es so lang dauert. Ja nee, also wirklich schnelle Tests sind ein Muss an der Stelle. TDD, wo man lange auf Feedback wartet, macht keinen Spaß.
Alex: [00:44:25.27] Und deswegen auch sage ich immer wir bewegen uns hauptsächlich auf diese Unit- und Micro-Test Ebene, weil des sind die schnellsten Tests.
Matthias: [00:44:33.37] Genau.
Alex: [00:44:34.63] Ich will sofort Feedback bekommen innerhalb von Sekunden, nicht innerhalb von Minuten, weil sonst führe ich die Tests irgendwann amal nicht mehr. Da mache ich kein TDD mehr, sondern schreibe ich einfach Code und -. Nee, das wollen wir nicht, wenn wir TDD machen, müssen die Tests schnell sein und die Ergebnisse schnell da sein auch tausend Tests in wenige Sekunden. Und wichtig ist auch, wie du gesagt hast. Wir konzentrieren uns auf Was will ich aufrufen, mit welche Parameter ich das aufrufen muss und was erwarte ich als Ergebnis? Also diese Interface auf die Funktionalität, die ich erwarte und wie diese Funktionalität implementiert ist, ist mir eigentlich in dem Test völlig egal. Die technische Implementierung ist in diesem Fall wurscht. Für den Test ist nur relevant eben, dass ich weiß, was ich aufrufe, mit welche Parameter, um was ich zurück bekomme. Darauf basierend testen wir.
Matthias: [00:45:34.93] Genau das ist auch was, wo ich am Anfang wirklich Probleme hatte, auch diese Abgrenzung zu finden. Also wo kann ich aufhören zu testen. Und es ist halt wirklich ganz häufig so, wenn ich mich auf Funktionalität von anderen Libraries oder sowas verlasse, die muss ich nicht zwingend testen. Also klar, ich muss das, was mein Code damit macht, das muss ich schon testen. Aber ich muss nicht testen, das die Funktionalität der Dritt-Library wirklich so funktioniert wie versprochen, weil dafür sind den ihre Tests zuständig, das sicherzustellen.
Alex: [00:46:13.75] Ja.
Matthias: [00:46:15.51] Okay, so das würd ich sagen, das reicht dann erst mal für heute. Wir haben etz doch schon ganz schön lang gemacht. Du hast jetzt einiges gehört über TDD, wie man das Ganze verwenden kann und welche Vorteile das mit sich bringt. Aber hast du auch ein bisschen was darüber erfahren, welche Schwierigkeiten wir damit haben können? Aber auch, wie man die unter Umständen meistern kann.
Alex: [00:46:37.32] Damit ist aber noch nicht alles gesagt und wir werden die nächste Folge in sechs anstatt in drei Wochen veröffentlichen. Warum? Weil wir ein Experiment wagen möchten.
Matthias: [00:46:48.00] Und zwar möchten wir ein Video zu dem Thema TDD noch auf unserem YouTube-Kanal veröffentlichen, wo wir uns dann noch mit weiteren Unterarten von TDD auseinandersetzen werden. Da gibt’s nämlich zum Beispiel die sogenannte Outside-In und die Inside-Out Methode.
Alex: [00:47:06.93] Genau. Wir werden diese extra Folge außerhalb des Podcasts veröffentlichen. Dafür werden wir, wie Matthias gesagt hat, unser YouTube-Kanal verwenden. Und natürlich werden wir unsere Macht-der-Craft- Newsletter informieren, sobald wie es draußen ist. Voraussichtlich wird in drei Wochen also ersetzt halt die nächste Podcastfolge, weil wir finden, dass es eine runde Sache machen würde, wenn wir ein bisschen ein Beispiel in Form eines Videos mal anbringen.
Matthias: [00:47:34.50] Und natürlich haben wir uns wieder sehr gefreut, dass du wieder mit dabei warst und würden uns auch freuen und den Podcast natürlich abonniert ist und auch andere Menschen auf uns aufmerksam machst, damit wir alle zusammen schön viel lernen können.
Alex: [00:47:48.30] Vielen Dank fürs Zuhören und bis bald.
Matthias: [00:47:51.21] Genau. Vielen Dank. Und bis bald. Macht’s gut.
Off: [00:47:55.59] Die Macht der Craft arbeitet für dich.