Matthias: [00:00:04.00] Hallo und herzlich willkommen zu einer neuen Ausgabe von der Macht der Craft, mit mir, Matthias

Alex: [00:00:09.46] Und wie immer auch mit mir der Alex. Wir wollen heute über BDD, ATTD und Spezification by Example sprechen.

Matthias: [00:00:18.64] Zusammen wollen wir ergründen, was es mit den Begriffen auf sich hat und wie das mit TDD und der Test Pyramide in Verbindung steht.

Alex: [00:00:25.90] Wenn du dich fragst, was das alles ist und was dir das bringt, bist du hier genau richtig.

Matthias: [00:00:32.86] Aber auch wenn das alles nicht neu für dich ist, wird hoffentlich der eine oder andere interessante Gedanke für dich auch dabei sein.

Alex: [00:00:39.13] Dann wollen wir loslegen.

Matthias: [00:00:40.84] Viel Spaß mit dieser Ausgabe.

[00:00:43.66] Die Macht der Craft arbeitet für dich.

Matthias: [00:00:48.75] Also wir wollen uns heute ja über ATDD, BDD und Spezification by Example unterhalten. Zuallererst würde ich mal ganz kurz klären, was diese Abkürzungen in erster Linie, für was die stehen. Und dann schauen wir mal weiter, wie was dahinter steckt. Also fangen wir mal an mit ATDD. Das steht letztendlich für Akzeptanz Test Driven Development und BDD, das ist Behavior Driven Development. Ich habe die letzten Tage viel zu den Themen gelesen und für mich persönlich entsteht da sehr schnell der Eindruck, dass die sich relativ ähnlich sind, dass die sich gar nicht groß unterscheiden. Alex Wie siehst du das? Siehst du das ähnlich?

Alex: [00:01:37.83] Okay, auf die Gefahr hin, dass jetzt alle Puristen den – die Hände über dem Kopf schlagen, mich Häretiker nennen oder solche Sachen. Für mich ist Im Großen und Ganzen sind alle drei ATTD, BDD und Spezifikation by Example eigentlich das gleiche mit kleinen Unterschieden. Im Großen und Ganzen zielen die auf auf dasselbe. Und deswegen finde ich gut, dass wir alle drei zusammen behandeln, weil eigentlich geht es um alle drei, um das gleiche Ziel. Die verfolgen das gleiche Ziel.

Matthias: [00:02:11.83] Ja ne, klar, grundsätzlich bin ich da ja der gleichen Meinung. Wie gesagt, ich habe viel gelesen dazu und ja, gefühlt unterscheiden sich in Nuancen. Also so habe ich zum Beispiel relativ häufig gelesen, dass eben zum Beispiel ATDD sich mehr darauf fokussiert, dass Akzeptanzkriterien eingehalten werden und erreicht werden. Und bei BDD wurde immer herausgestellt, dass es sich mehr auf das Verhalten des Systems konzentriert und dass das korrekt ist. Aber wenn man also zumindest für mich erscheint es trotzdem das Gleiche zu sein, weil wenn ich meine Akzeptanz Kriterien einhalte, dann verhält sich hoffentlich auch mein System richtig. Deswegen finde ich es persönlich auch schwierig, da wirklich Unterschiede herauszuarbeiten. Und das sind wirklich nur so Nuancen. Deswegen – also ich würde es tatsächlich auch eher synonym betrachten und ich würde auch sagen, dass keines dem anderen in irgendeiner Weise überlegen ist, weil wie gesagt letztendlich sie wollen alle das gleiche erreichen, nämlich dass das System, das wir an dem wir arbeiten, dass es nicht nur Dinge richtig macht, was wir mit Unit Tests und Micro Tests und sowas sicherstellen wollen, sondern eben, dass es auch die richtigen Dinge macht und dass wir das Ziel von unserem Software System insofern erreicht wird, dass es tut was es soll.

Alex: [00:03:50.39] Bin voll bei dir. Alle drei in meinen Augen sind eine Möglichkeit, das Verhalten der Anwendung zu beschreiben in Form von Tests. Und zwar das machen wir sehr oft und es funktioniert auch sehr gut mit Beispiele. Was erwarten wir, dass die Anwendung tut in Fall xyz. Deswegen auch Spezifikation bei Example. Also wir definieren Beispiele, die wir dann als Test gießen und wenn – ja – diese Tests grün sind. Gehen wir mal davon aus, dass die Anwendung das tut, was wir als Beispiele spezifiziert haben. Diese Tests sind für mich auch deutlich fachlicher. Ja, es geht um um Business Logik, um Business Geschichten und nicht um die technische Funktionalität, wie wir es auf Micro- oder auf Unit-Test Ebene behandelt haben. Denn wie gesagt eben wer fachlich oder Business Regeln basiert. Und für mich ganz wichtig ist, diese ATDD, BDD diese Spezifikation bei Example Geschichten sind Sachen, die auch vom Tester oder von nicht technische Entwickler verstanden werden soll. Sie müssen in der Lage sein, der Test zu lesen und zu verstehen, was da passieren oder passieren soll. Zum Beispiel ist immer super von meinem beim Product Owner immer super gewesen, wenn wir diese ATTD Geschichten hatten, dass er in der Liste der Tests deutlich, klar, gut beschrieben fand: Ok, diese Fall, die wir abdecken müssen, ist abgedeckt und funktioniert

Matthias: [00:05:35.83] Ja, aber das ist auch eh nur ein Punkt, auf den ich auch nur zu sprechen kommen wollte. Das ja bei der Entwicklung von diesen Tests sind ja auch schon nicht nur Softwareentwickler Programmierer involviert, sondern eben auch ein viel breiteres Spektrum an Leuten, zum Beispiel Fachexperten. Und wie du auch schon gesagt, dass eventuell der PO oder andere Teilnehmer oder Stakeholder an dem Projekt.

Alex: [00:06:02.05] Ich kann dir erzählen, wie ich mir den Prozess vorstelle oder wie ich den Prozess erlebt habe, wie ich es in meiner Erfahrung in Erinnerung habe, wie wir das alles gemacht haben. Und das beschränkt sich nicht nur auf die technische Implementierung, sondern da gibt es etliche Schritte, die vorher kommen. Und zum Beispiel als erstes braucht man ein gutes Verständnis von das, was wir implementieren müssen, was wir programmieren müssen. Das kann man auf unterschiedliche Weise erreichen. Weiß nicht, ob dir das Konzept der drei Amigos für dich was ist, aber das heißt zum Beispiel mit einem Fachexperten, Tester, Entwickler. Die sitzen alle zusammen und versuchen Akzeptanzkriterien oder die Beispiele vor dem Verhalten mal zu eruieren und zusammen in Form zu bringen, sodass wir alle das gleiche Verständnis haben von das, was wir tun wollen. Es gibt auch Möglichkeiten, wenn wir in Microservices Gedanken zum Beispiel gehen, so was wie EventStorming zu machen, wo dann auch Business Experten, POs technische Leute, Tester was auch immer alle zusammen halt dann in einen Haufen an das Verständnis von das, was wir im Endeffekt machen müssen arbeiten, sodass wir alle das gleiche verstehen, dass sich eine gemeinsame Sprache bildet, wo wir alle das gleiche verstehen, wenn wir die gleiche Begriffe verstehen usw. Und das wäre für mich der erste Schritt.

Alex: [00:07:35.29] Der zweite Schritt ist dann diese Akzeptanz Kriterien irgendwie in Tests zu gießen. Da eignen sich Sachen wie Cucumber zum Beispiel gut dazu. Das kann vom Tester selber implementiert werden oder vom Business Experte, wenn er zum Team gehört und so weiter. Und dann gehört auch die Implementierung von diese Test, also nicht nur die dessen Beschreibung mit Cucumber, sondern auch der sogenannte Glue-Code, die die tatsächliche Anwendung mit dem Tests verknüpft. Die kann auch meinetwegen der Tester oder der Bildungsexperte machen, wenn er das kann. Und ansonsten wird dann gemeinsam mit dem Entwickler diese Themen angegangen. Wichtig ist zum Beispiel für mich, dass bei der Definition der Tests wir völlig unabhängig von der Implementierung bleiben. In diese Beschreibung von der Test, die oder von diesem Beispiele oder von diesem Verhalten, die ich überprüfen möchte, ja, wünsche ich mir halt mal was. Ja, wenn das und das ankommt, dann muss das und das rauskommen. Und wie es reinkommt, wo wir, so wie es die tatsächliche Implementierung ist, jetzt erst einmal egal. Das brauchen wir dann, wenn wir den Glue-Code mal erstellen. Aber das kann man wie gesagt gemeinsam mit den Entwickler zusammenschreiben, sodass die Sachen, also die die Tests und der Glue-Code zusammen zu der Implementierung, die da vorgenommen wird, zueinander passen. Findest du das gut? Nicht gut, besser, Paulaner?

Matthias: [00:09:14.20] total gut, besser? Nein, finde ich natürlich gut. Ich kenne den Prozess auch tatsächlich. Manchmal sind es nicht nur drei Amigos in meiner Erfahrung, sondern fünf oder so, aber das sei mal dahingestellt. Und das jetzt auch nur die fünf Amigos, weil dann halt irgendwie drei Fachler da sind, statt einer. Aber egal. Nee, an und für sich bin ich voll bei dir. So würde ich den Prozess auch sehen. Und ich finde ihn eigentlich auch so ganz gut. Trotzdem noch einen Unterschied, den man feststellen kann, glaube ich. Bei ATDD und BDD ist das bei BDD es ein bisschen mehr Vorgaben gibt, wie man Tests schreiben soll. Also da gibt es dann im Prinzip ja dieses Given/When/Then. Also dafür gibt’s es natürlich dann auch wieder innerhalb – also wenn man jetzt beim Beispiel Cucumber zum Beispiel bleiben natürlich Synonyme. Das heißt, ich muss nicht immer die Wörter given/when/then benutzen, aber es gibt immer diese strikte Trennung nach etwas ist gegeben, etwas passiert und ich erwarte etwas. Und diese strikte Vorgabe, die habe ich jetzt bei ATDD so zumindest nicht gefunden. Das wäre noch so ein Unterschied, den ich gefunden habe, aber ansonsten finde ich, sind die sich tatsächlich relativ ähnlich.

Alex: [00:10:38.41] Bei ATDD ist nicht vorgegeben oder zumindest kenne ich es auch nicht. Nicht vorgegeben, wie die Tests geschrieben werden muss und bei BDD schon, aber wenn du diese dieses Schema gegeben sei, wenn dann weiter folgst, dann mach es eigentlich das gleiche.

Matthias: [00:10:54.34] Ja genau. Also dann wird das ganz schnell zu BDD. Also ich meine, wir haben uns in den letzten Folgen, als wir mal über TDD geredet haben, da haben wir ja auch über diese Unterteilung gesprochen, die wir in unseren Tests machen mit den drei As, also Arrange/Act und Assert. Und wenn man da genau hinschaut, sind diese drei Begriffe ja auch nur Abänderungen von Given/When/Then also zu einem gewissen Grad teilen wir sogar ja teilweise unsere Unit Tests schon genauso auf, wie BDD das gern hätte. Und ich finde es auch keine schlechte Aufteilung. Also weil ja das ganz klar irgendwo aufzeigt, wo was innerhalb meines Tests passiert.

Alex: [00:11:44.35] Und vor allem ist aber für mich der Unterschied der große Unterschied zwischen TDD und und diese andere Methode ATDD, BDD – Ja und da wären wir bei dem Thema wo befinden wir uns in die Tests Pyramide eigentlich? Ist, dass wir hier eher wie gesagt fachliche Ebene, Business Logik, Verhalten testen und nicht Klein-Klein jede Klasse, wie wir es in in Unit Tests gemacht haben testen. Ja genau, es geht um um größere Zusammenhänge.

Matthias: [00:12:23.56] Exakt. Also ich würde auch sagen BDD und ATDD befinden sich in der Test Pyramide eher so im in den oberen zwei Dritteln und nicht auf Unit Tests Ebene. Es gibt auch tatsächlich BDD Unit Tests Frameworks, aber die sind jetzt nicht so verbreitet wie die Standard-Frameworks würde ich mal behaupten.

Alex: [00:12:46.18] Ich würde ATDD, BDD, diese Methoden eher auf Integrations Ebene oder weiter weiter oben, auch für End-To-End-Tests kann ma ATDD und BDD verwenden.

Matthias: [00:12:59.19] Genau.

Alex: [00:13:01.42] Und weiter weiter im Text. Aber dass wir TDD und ATDD oder BDD und Spezifikation bei Example und Dings und Bums und alles mögliche, das ändert nicht daran, dass wir auch weiterhin manuelle Tests brauchen werden. Nun noch mal zu erwähnen.

Matthias: [00:13:19.36] Genau, also die die manuellen Tests fallen deswegen genauso wenig weg wie in unsere letzten Folgen. Und das ist auch nichts, was wir irgendwie postulieren wollen, dass das überflüssig wäre oder sonst was. Aber noch ein anderer Punkt ist, weil es ist auch etwas oder ein Missverständnis, das ich häufig in meinen Recherchen mitbekommen habe, ist das teilweise die Meinung besteht, wenn ich mit BDD, ATDD arbeite, dann bräuchte ich die Unit Tests nicht mehr und das halte ich halt persönlich für – ja – gefährlich.

Alex: [00:13:54.55] Krasse Fehler, ja,

Matthias: [00:13:56.95] Weil also in meinen Augen ist gerade die Kombination aus den Techniken des wirklich starke, also BDD, ATTD nutz ich, um das Verhalten meines Systems zu beschreiben und die fachlichen Anforderungen daran und TDD benutze ich letztendlich, um die technische Richtigkeit sicherzustellen, während ich diese Funktionalitäten entwickle, die ich brauche, um meine Anforderungen zu erfüllen. Wie siehst du das?

Alex: [00:14:34.11] Ja, kann ich mit leben.

Matthias: [00:14:35.64] Kannst du mit leben, freut mich

Alex: [00:14:39.69] also auf jeden Fall ersetzt das eine nicht das andere, da hast du völlig recht. Ich hatte aber mal eine sehr metaphysische Diskussion. Und zwar wenn wir eine von diesen Methoden verwenden, um unsere das Verhalten, unsere Anwendung zu prüfen, dann entstehen diese zum Beispiel Cucumber Tests und wir brauchen diese sogenannte Glue Code. Ja, das ist Code, die geschrieben wird, die die Tests mit unsere Anwendung irgendwie verbinden. Und aber wir haben ja der Wunsch, der Wille sozusagen, dass unsere Code Qualität überall gut ist, auch in den Tests. Ja, da war die ganze – ja – kritische Frage ist: müssen wir unsere Glue Code auch mit TDD entwickeln? Oder kann man es ohne entwickeln oder hat es überhaupt Vorteile, wenn wir es mit TDD entwickeln oder nicht? Oder können wir einfach nur den produktiven Code mit TDD entwickeln und unsere Glue Code einfach als eine Anwendung betrachten, die von außerhalb auf unsere System zugreift? Was hältst du davon?

Matthias: [00:16:00.37] Naja, also ich würd mal sagen ‚it depends‘. Also meiner Ansicht nach ist es wirklich meine ganz persönliche Meinung, sollte Glue-Code, der jetzt ja in Cucumber dafür da ist, die fachlichen Einzelschritte und da ist die Betonung auf Einzelschritte für mich auf eine technische Ebene übersetzt und das Software System anspricht füttert von außen in erster Linie. Und solange ich in Einzelschritte bleibe und in meinem Step passiert genau eine Sache, nämlich dass eine öffentliche Methode aus meinem Software System mit einem gewissen Input angesprochen wird, sehe ich persönlich keinen Grund diesen Aufruf zu testen. Weil wenn ich die Klasse, die ich dort aufrufe mit TDD entwickelt hab, dann ist die getestet und dann muss ich nichts testen. Und wenn ich in meinem Glue Code irgendeine extra Logik drinnen habe, um irgendwas vorzubereiten, dann ist es in meinen Augen keine Einzelschritte. Und dann habe ich in meinem Cucumber Test Design in meinen Augen irgendwo einen Fehler gemacht. So ist meine ganz persönliche Meinung dazu. Also ich will nicht sagen, das ist die einzig wahre Sache ist aber so würde ich an die Sache rangehen.

Alex: [00:17:23.29] Also ich kann sagen, wir sind zu keinem Entschluss gekommen. Ja, es gab ja Vertreter von beiden Parteien. Ja, wenn ich TDD nutze, dann muss ich überall TDD nutzen und und und und und. Aber mir erschließt sich auch der Gewinn da nicht. Was habe ich davon, wenn ich den Glue Code als auch mit Tests versehen? Also wenn ich mir TDD machen, um den Code zu schreiben, versehen wir der Test Code mit Tests.

Matthias: [00:17:54.16] Ja genau. Und dann müsste ich rein theoretisch auch mein TDD Code testen und dann bist du in so einer Endlosschleife, die dann irgendwann keinen Sinn mehr ergibt. Und ja, wie gesagt, also in meinen Augen, wenn ich wirklich gezwungen bin, in meinem Cucumber Einzel Stepp Dinge zu machen, die Test würdig sind, dann habe ich in meinen Augen etwas falsch gemacht.

Alex: [00:18:18.88] Das sehe ich aber anders als du. Okay, meinte ich dann meine bei Definitionen allgemein halten, fachlich halten. Ja, zum Beispiel kann ich einfach eingeben in meine Verhaltens Definitionen: „gegeben sei: Der Benutzer hat zwei Artikel in den Warenkorb, dann, wenn er den Warenkorb aufmacht, sind diese zwei Artikel sichtbar.“ Dies wäre ein für mich ein valide Cucumber, und abhängig davon aber auf welcher Ebene du dieses Problem löst, ob du es in ein End-to-End-Test oder in ein auf ein Integrationsebene, zum Beispiel kann es sein, dass zum Beispiel das gegeben sei, ja, dass zwei Artikel in den Warenkorb gelegt worden sind, durchaus mehrere Operationen beinhalten. Für mich ist dadurch der Test nicht weniger gut. Verstehst du, was ich meine?

Matthias: [00:19:17.08] Ja, aber ich würde halt trotzdem argumentieren, dass die Methoden, die du aufrufst, um diese Sachen hinzuzufügen, die sind ja getestet. Und wenn, dann sprechen wir ja darüber, dass die Sachen, die ich jetzt in meinen Cucumber-Step reingeb, also in dem Fall jetzt die 2 zum Beispiel, die entscheidet ja, also die macht ja den Unterschied bei dem Step. Wenn ich sage, ich habe zwei Produkte in meinen Warenkorb, dann kann ich ja theoretisch auch sagen Ich habe drei Produkte. Das heißt, wenn ich hier zwei reingeht und eine drei, dann verhält sich das ganze Ding ein bisschen anders. Aber die Methoden, die aufgerufen werden, sind ja trotzdem drunter getestet, weil mit TDD entwickelt und ja, aber wie gesagt, ich meine, wir müssen da jetzt auch nicht uns ja zerdiskutiern, weil alles in allem ich glaube, da wird man auch keine endgültige Lösung finden an der Stelle,

Alex: [00:20:17.36] Dann denke ich auch nicht. Ich fand nur, es ist ein interessanter Gedanke.

Matthias: [00:20:20.35] Halt mal ist das ich persönlich? Also ich persönlich würde mich dagegen wehren, weil wie gesagt, ich finde dann kann man unter Umständen, wenn man Cucumber oder das Feature File dann ein bisschen anders schreibt, es anders hinbringen. Also wenn ich jetzt statt zum Beispiel einen Step hab, wo ich sage, ich habe zwei Sachen im Warenkorb, kann ich ja auch sagen, ich habe ich habe zwei Steps dafür und sage Ich habe einmal Produkt X im Warenkorb und ich habe einmal Produkt Y im Warenkorb. Und dann bist du nämlich wieder genau an der Stelle, wo du einfach nur den den variablen Wert, den du von dem Step bekommst, in eine bereits getestete Methode rein gibst. Bestimmt alles seine Vor und Nachteile. Aber ja. Also ich persönlich bin auf jeden Fall der Meinung, dass man Glue Code nicht testen müssen sollte. Sollte müssen? Nein, also ich in einer schönen Welt müsste es nicht notwendig sein Glue Code zu testen, meiner Meinung nach.

Alex: [00:21:23.53] So ist ja die starke Meinung ja im echten Leben durch normalerweise das Glue Code nicht separat testen, sondern gehe ich davon aus, dass über die Tests, die in der Anwendung sind, das schon genug abgedeckt ist.

Matthias: [00:21:39.88] Hmm, wie gesagt, ich würde einfach versuchen, auch wenn ich Cucumber Tests schreibe, die so simpel wie möglich zu halten und nicht zu viel Komplexität reinzubringen. Und dann wird diese Diskussion hoffentlich gar nicht so stark aufkommen.

Alex: [00:21:57.13] Bezüglich die Formulierung von der von diese Tests Nee, man sollte so fachlich wie möglich bleiben und zum Beispiel auf Integrations Ebene. Wenn ich die verwende, erlaube ich mir schon etwas technischer zu sprechen. Aber wenn wir zum Beispiel auf höherer Ebene, End-2-End-Test oder sowas. Da sind schon fachliche Beschreibungen für mich notwendig, dann geht es nicht, wie es technisch passiert ist eigentlich da oben völlig egal, sondern es geht nur um das Verhalten der Anwendung und nicht ob Methode X oder Methode Y verwendet wird. Es ist für mich auch wichtig, dass das gesehen wird. Das sind keine technische Tests. Die Tests sind keine technische Gegebenheiten, sondern die testen Verhalten. Sie testen Akzeptanz Kriterien, die Tests in einem Beispiel, bis ich die Anwendung zu verhalten hat.

Matthias: [00:22:54.43] Hmm, okay. Wir haben ja jetzt quasi verortet, wo diese Techniken Einsatz finden können innerhalb der Test Pyramide und haben auch geklärt, dass das eine zu benutzen nicht bedeutet, dass ich auf das andere verzichten sollte oder könnte. Und jetzt ist die Frage in meinen Augen noch kann man die Sachen sinnvoll kombinieren? Und meiner Meinung nach ja. Also wir glaube ich habe vorhin auch schon mal angerissen, dass ich aus meiner Sicht die BDD oder ATDD Tests nutzen würde, um die fachliche Richtigkeit meiner Anwendung sicherzustellen und sozusagen den Rahmen zu definieren. Und TDD würde ich dann letztendlich auf Unit-Test-Ebene in der im unteren Teil der Pyramide eben benutzen, um die technische Richtigkeit der Einzelkomponenten meiner Anwendung sicherzustellen. Siehst du da noch irgendwas anderes?

Alex: [00:23:58.05] Klingt nach einem Plan,

Matthias: [00:23:59.85] Klingt nach einem Plan.

Alex: [00:24:01.25] Ja echt. Ich finde es auch so mit TDD würde ich eher wie gesagt wie du gesagt hast eher technische Tests auf Unit Tests, gegebenenfalls auch auf eine technische Integrations Ebene, in den ich nur das Zusammenspielen von zwei oder drei oder mehrere Klassen eruieren will, abtesten will. Und diese andere Technologien nennen wir sie anderes DD.

Matthias: [00:24:29.91] Anderes DD

Alex: [00:24:32.82] ATTD, BDD, Specification by Example wie auch immer, die setzen auf eine höhere Ebene sowohl in der Pyramide wie auch in den Zusammenhang, dass sie eher fachlich gehalten werden. Es geht um Business Logik, es geht um eine Business Spezifikation, eine Verhaltens Spezifikation und nicht um die technische Prüfung. Es bilden diese zwei Unterschiede. Erstens es ist höher in die Pyramide, eher auf höhere Integrationsebene oder End-To-End-Tests oder was auch immer. Und zweitens ist eine fachliche Geschichte, eine Business Geschichte, keine technische Geschichte, die wir da prüfen wollen. Eins, was wir nicht erwähnt haben, aber das ich auch wichtig finde, ist, da wir uns weiter oben in der Test-Pyramide befinden, sind diese Tests üblicherweise langsamer als unsere Micro-Tests. Da habe ich auch üblicherweise weniger davon und führe sie nicht so oft wie meine Micro-Test. Im TDD Prozess führe ich meine Micro Tests dauernd und ich könnte mir vorstellen, diese Akzeptanz Tests zum Beispiel nur einmal, bevor ich einchecke, oder bevor ich commite lokal auszuführen und natürlich auch wenn die schnell genug sind, also wenn die keine halbe Stunde brauchen, auch in die CI. Zack laufen lassen. Aber lokal führe ich sie zum Beispiel nicht einmal die Minute, wie ich meine Units zum Beispiel ausführen würde wenn ich im TDD Zyklus bin. Das ist auch für mich eine wichtige Unterschied zwischen TDD und diese andere Methoden.

Matthias: [00:26:17.88] Ja, ich. Für mich persönlich ist BDD dann auch eher so dieses Cucumber Gherkin Syntax, dass man einfach in natürlicher, englischer oder deutscher Sprache, je nachdem wie man das Framework konfiguriert, seine Tests schreiben kann und letztendlich dann mithilfe von Glue Code wie du vorhin schon gesagt hast, des eigentliche Software System dann anspricht. Ich meine dadurch, dass wir in der Test Pyramide relativ weit oben sind, hast du ja scho gsagt, haben wir weniger davon. Eventuell ist es noch interessant zu klären wie – also woher weiß ich denn was ich testen will auf der Ebene eigentlich mit BDD und ATDD, weil dadurch, dass ich weniger Tests da bedeutet ja letztendlich irgendwo auch, dass ich unter Umständen zumindest weniger Dinge teste. Also was sind denn die wichtigen Dinge vielleicht?

Alex: [00:27:15.04] In meinen Augen, fange ma da immer mit positiv Fälle, also das sogenannte Happy Path. Dann kannst du von da aus weitere Tests machen, Variationen von Happy Path, eventuell auch noch in wichtigen Fehlerfällen, aber ich würde jetzt nicht jede mögliche Kleinigkeit testen, weil wie gesagt, die dauern schon länger an sich. Also wenn ich viele, viele davon habe, macht die Ausführung extrem langsam und je langsamer die Ausführung ist, meiner Erfahrung nach, desto weniger werden die Tests ausgeführt. Und wenn ich Tests habe, die ich nicht ausführe, die nutze mir gar nicht.

Matthias: [00:27:58.60] Ja. Also, ich glaube tatsächlich, für mich ist da das Zauberwort Business Value, wenn man so will. Also welche Funktionen meines, meiner Anwendung liefern den meisten Wert? Und da würde ich den Fokus drauf legen. Also wenn man jetzt über so eine klassische Software System sprechen, das in irgendeiner Weise Wert generiert, dann muss ich sicherstellen, dass diese Kern Funktionalität funktioniert. Und dafür würde ich letztendlich dann so BDD oder ATDD Tests verwenden, um diese wichtigen Funktionalitäten, die letztendlich dafür sorgen, dass mit diesem Software System Geld verdient werden kann, dass die auch funktionieren.

Alex: [00:28:41.03] Wunderbare Gedanke.

Matthias: [00:28:42.85] Ja ne?

Alex: [00:28:44.56] Geld verdienen ist immer gut.

Matthias: [00:28:48.76] Irgendjemand muss ja die Softwareentwickler und Entwicklerinnen bezahlen, die das ganze dann auch in die Tat umsetzen.

Alex: [00:28:55.78] Ja, aber

Matthias: [00:28:57.73] Deswegen müssen wir tatsächlich Fokus auf die Sachen legen, die irgendwo auch Wert liefern. Und wie dieser Wert letztlich aussieht, das steht wieder auf einem anderen Papier.

Alex: [00:29:09.05] Wir sind am Ende gekommen und das ist der Abschluss der Miniserie. Tests gehören auch dazu.

Matthias: [00:29:16.88] Wir haben in den letzten Folgen sehr viel über die unterschiedlichsten Arten von Tests gelernt,

Alex: [00:29:21.62] Von grundlegenden Fragen bis zu fortgeschrittenen Konzepten. Hast du alles gehört?

Matthias: [00:29:27.65] Wir hoffen, du konntest viel lernen und bist auch in Zukunft wieder mit dabei, wenn wir über andere Aspekte der Craft sprechen.

Alex: [00:29:34.76] Wenn du keine Folge verpassen willst, abonniere einfach unser Podcast

Matthias: [00:29:39.20] Und wenn du die Macht der Craft mit anderen teilst, hat jeder was davon.

Alex: [00:29:43.92] Es ist genug Craft für alle da.

[00:29:47.62] Die Macht der Kraft arbeitet für dich.