Der guckt so in den Netzwerk Traffic so rein. Oh ja, Oh ja, der Funk wurde aufgerufen, Oh ja, sehr gut Coding Buddies Dein Podcast rund um Softwareentwicklung und aktueller Tech News herzlich willkommen. Moin Moin und Herzlich Willkommen zum Coding Buddies Podcast. Eine Woche ist rum, es ist wieder soweit, neue Folge steht in den Startlöchern. Hier und damit möchte ich auch. Tino, der mir hier schon gegenüber sitzt und Grimassen schneidet.
Zustimmende Grimassen begrüßen. Ich wollte mal sehen, wie fokussiert du sein kannst. Was geht ab, Vati, was geht, was geht, was geht. Neue Woche, neues Glück wa ja. Ja klar, auf jeden Fall. Eigentlich immer so jede Woche.
Ja, ja, weißt du doch. Aber diese Woche war auf jeden Fall was cooler diese Woche letzte Woche eigentlich offiziell, letzte Woche noch war ja was Cooles, da waren wir ja bei der Testkonf, das ist ja ne, ich sag mal ne Konferenz online rein online, die auf Twitch gestreamt wird und das ist so wie man sich das halt normal vorstellt. Ne du hast so verschiedene Speaker und Speakerinnen, die dann halt eben ihre Beiträge in den entsprechenden Slots.
Zum besten gegen geben ne und da haben waren wir auch dabei. Du und ich als Coding Buddies wie man uns so kennt und hatten ja auch NN Slot, konnten da n bisschen was über TTD und Pair Programming erzählen und da gab es ja noch ne Frage am Ende die so n bisschen ich glaub wir hatten nicht mehr ganz so viel Zeit das zu beantworten und da haben wir uns gedacht machen wir noch mal ne. Podcast Folge darüber und beleuchten das noch mal n bisschen genauer, ne.
Ja genau, und zwar wir hatten ja wirklich viel über Tdd gesprochen, hat noch so ne live Demo gemacht, Liebe zuhören lieber Zuhörer, falls du dich dafür interessierst. Man kann ja jetzt noch keine Ahnung ein 2 Monate wie lange kann man sich VODS auf Twitch angucken? Kommt drauf an, wie man es einstellt.
Glaube ich ja. Ich glaube maximal 3 Monate oder so, aber auf jeden Fall aktuell kann man sich da die Konferenz noch angucken, weil es ist wie gesagt Free und es lohnt sich, sind sehr coole Vorträge bei gewesen. Und falls du Bock hast, unseren dir anzuschauen, dann kannst du den da auch finden und danach wird es glaube ich noch auf Youtube hochgeladen, aber das ist aktuell noch nicht der Fall.
Also es wird noch persistiert und zu der Frage genau die Fragerunde war ja sag ich mal n bisschen knapp ausgefallen, weil wir n bisschen getrödelt haben und da kam halt die Frage OKTDD verstehe ich, dass ihr das so macht? Das ist cool. Wie steht denn ihr zum Thema BDD? Und wie ergänzt das TDD?
Jetzt kommen die ganzen Abkürzungen, wir erklären sie gleich ABC und ja, da bin ich halt nur kurz drauf eingegangen und da dachte ich mir, ey, fabi, ist da eigentlich ne coole Frage gewesen und BDD ist auch n sehr spannendes Thema, also lass uns doch einfach direkt ne Podcast Folge im Anschluss da drüber raushauen. Und das würd ich halt gerne heute mit dir machen. Auf jeden Fall, um das ganze Mal
quasi einzufangen. Also BDD ist vielleicht nicht jedem Begriff, ich muss ehrlich sagen, ich hab auch kurz nachgedacht, wo ich die Frage gelesen hab, weil die war ja so im Chat, es geht dabei um Behavior Driven Development, also bei TDD gibt es haben wir auch ne Folge zu gemacht, das ist ja quasi eine Praxis oder eine Strategie sag ich mal die wir in. Sag ich mal als Coder Leben und integriert haben in unseren Coding Alltag auch im beruflichen Kontext. Und das ist ja Test driven
development. Noch mal ganz kurz, da geht es ja darum, dass man quasi erst den Test schreibt sieht, diese Funktionalität ist nicht implementiert, der Test ist rot, man implementiert ist und sorgt dafür, dass der Test erfolgreich ist. Grün refact das noch und das ist so die Arbeitsmethodik, dass du sagst erst testen, dann implementieren. Genau. Bei BDD geht es, geht man jetzt sag ich mal das ganze noch n Schritt weiter, also ganz am Anfang mal der Disclaimer.
Ja es geht jetzt nicht darum TDD mit BDD zu ersetzen, sondern on top das Ganze das noch mal ganz klar, dass das hier nicht in falschen Hals kommt. Wir wollen heute mal beleuchten, wie kann man jetzt das Prinzip von Behavior Driven Development nutzen um es quasi mit. Test Driven development zu
verbinden. Genau das ist auf jeden Fall ne gute ne gute Beschreibung zu verbinden zu erweitern, weil man kann TDD auch ohne BDD machen sozusagen, aber es wird glaub ich einfach schöner wenn man BDD noch mit dazu nimmt um jetzt mal so n bisschen vielleicht so diesen Painpoint zu adressieren, ne weil BDD was das jetzt quasi so.
Genau ist, worum es da geht. Find ich hab ich mal so n kleines Beispiel mitgebracht, dass man sich so vielleicht hineinversetzen kann und vielleicht auch sich denkt, Boah ich kenn das, das ist irgendwie ne Sache, die hab ich nur leider viel zu oft mitgekriegt und wir glaub ich auch Tino wenn man jetzt zum Beispiel irgendwie ne im Berufsalltag sagt ich möchte irgendwas implementieren ne also irgendwas soll jetzt gemacht
werden. Und man denkt sich so, OK, ich hab ja irgendwie n so ne Story, ne wo jetzt dann drin steht was gemacht werden soll und jetzt stell dir mal ne Story vor, ne wo es darum geht. Du hast jetzt irgendwie ne ne Shopping Card ne und sollst jetzt n Endpunkt implementieren und da steht sowas wie Implementiere n Endpunkt Card at ne und die Methode soll ein Produkt Objekt zur Session hinzufügen. Wenn das Produkt bereits existiert, erhöhe die Quantity um 1 und verwende die Service.
Die Card Serviceklasse für die Persistenz. So könnte jetzt ne Story sein, mal als Beispiel wo ich glaube, also dass man das schon oft gehört hat, dass man zumindest so oft so ne Art und Weise schon mal vor sich liegen hatte und sich dann denkt hm. Also da könnte jetzt ne Menge mit passieren. Ne, also zum Beispiel, was bedeutet genau existiert ne heißt das der User hat schon Warenkorb oder existiert das Produkt bereits in diesem Warenkorb oder gibt es das überhaupt in diesem Katalog?
Ne soll der Nutzer irgendwie ne Bestätigung sehen? Was passiert eigentlich wenn das Produkt nicht verfügbar ist? Das sind ja alles fragen die man sich unter Umständen direkt irgendwie dir dir in den Kopf kommen und worauf ich hinaus will ist du hast ne Story, du hast irgendwie ne Aufgabe mit an der du arbeiten sollst und du fragst dich. OK, aber was soll ich hier eigentlich genau machen?
Da sind ja so super viele unklare Sachen und irgendwie ist es alles auf einer komischen Ebene erklärt, ja vielleicht teilweise technisch, vielleicht teilweise fachlich irgendwie vermischt, aber irgendwie so hingewurstelt weißt du? Ja, das also. Es klingt halt eher wie ne Story, die wahrscheinlich von einem Developer, also es ist jetzt nur so n bisschen leicht, provokativ, spaßig, ja von einem
Developer, oder? So geschrieben wurde fast schon wie nen Reminder. Ach ja, das muss ich implementieren, in der Klasse muss ich das noch machen und so und das ist halt so technisch, dass da ja quasi schon codeelemente auftreten, ne, also wenn du jetzt zum Beispiel sagst, bitte nimm die Klasse oder schreib eine Klasse sowieso und ich finde der Name ist Story, gerade wenn wir jetzt so im agilen sind, wir sind ja hier auch in der Agilität unterwegs, ja. Beschreibt ja Story an sich
schon, worum es eigentlich geht. Ne Story. Also wenn ich jetzt wirklich mal ne Geschichte erzähle, dann sag ich ja nicht, es war einmal eine Chartklasse, die hatte einen Service und der konnte sein. Was hast du gesagt seine Anzahl um 1 erhöhen wenn man den Add Endpunkt aufgerufen hat? Es war eine fantastische Geschichte, so weißt du das
machst du ja nicht, also die. Die die Namensgebung sagt ja schon oder lenkt das ja eigentlich schon in ne andere Richtung und da setzt ja auch BDD an, wenn man jetzt BDD in einem Satz erklären sollte, würde ich sagen, ist das Softwareentwicklung aus der Sicht des Benutzers, also des Endanwenders ne, Ich möchte jetzt Software aus der Brille des Users entwickeln und dann macht also im Prinzip man fokussiert sich nicht mehr so. Darauf, wie setze ich das um?
So wäre jetzt das Ticket oder die Story, die dein Beispiel war, umgesetzt. So wie machen wir das? Na ja, indem wir diese Klasse erweitern, indem wir diese Klasse schreiben, indem wir diese Funktion implementieren, darum geht es nicht, es geht eher um das warum, machen wir das ja, also ich möchte in der Story beschreiben, warum brauchen wir diesen Endpunkt, warum müssen wir.
Feststellen können, dass es jetzt ja Anzahl ich, ich hab es nicht mehr ganz auf dem Champs, ich glaub der Warenkorb, also ein Element mehr hat ja dass ich dann bloß 1 rechne oder sowas, das ist die Frage, ist ja nach dem warum, also wenn ich mich darauf fokussiere, ja dann komm ich halt viel mehr in die Sicht des Nutzers und vor allem auf eine sprachliche Ebene, die jeder verstehen kann und das ist n ganz. Wie soll ich sagen n Kernelement bei BDD ne.
Ja, auf jeden Fall. Ich find n gutes ne gute Beschreibung dafür, was ich da irgendwie ne Zeit lang mal gehört hab ist was für ein User Value gibt es ne? Also ich find diesen Begriff eigentlich ganz gut user Value weil das ist nämlich genau das wie du meintest worum es geht aus Sicht des Users. Was hat denn der User davon,
dass wir das gerade machen? Ne nicht wie machen wir das wie du es so schön meintest, sondern was bringt es diesem User also ne. Der User guckt sich dieses Produkt an, was gerade entwickelt wird und welchen Wert schöpft denn diese neue, dieses neue Feature sozusagen für den User? Ich musste mir gerade dran denken. Stell dir mal vor, so welchen Wert ist das für n User oder der guckt so in den Netzwerk Traffic
so rein. Oh ja Oh ja, der Endpunkt wurde aufgerufen Oh ja sehr gut 200 OK oh super. Gut, das ist aber richtig. User Value, dass der Card Service aufgerufen wurde, genau das ist ja gut. Genau das ist aber natürlich Spaß beiseite, natürlich nicht der User Value, ja wie du so schön, ich find den Begriff halt auch sehr stark sich darauf zu fokussieren zu sagen was schafft wirklich Value für den Endanwender ne oder oder manche sagen ja auch impact ne was hat wirklich impact am Ende so?
Genau und wichtig dabei ist ja wirklich dann einfach mal vom Fachjargon wegzukommen. Ist übrigens n witziges Wort Jargon davon wegzukommen und mal Tickets oder Stories so zu beschreiben, dass sie jeder versteht, einfach um sag ich mal, diese Unklarheiten aus dem Weg zu räumen.
Das Beispiel was du gemacht hast vorhin, ne, das hast du mir jetzt so einmal aufgesagt, ich hab es ja nicht mitgelesen, ja oder ich konnte es gar nicht mitlesen, du hast es mir gesagt, so und da war ich doch schon nach 2 Sätzen abgehangen, also
ich konnte. Jetzt zwar grob folgen, aber im Endeffekt denkt man drüber nach und denkt so ja OK und hier und da hä was wie hä hättest du mir jetzt einfach quasi auf nicht fachlicher ebene nee auf fachlicher Ebene so nicht auf technischer andersrum sorry das erklärt was du vorhast in diesem Ticket, dann wär ich einfach viel mehr bei dir gewesen, weil wir einfach direkt ohne irgendwelche technischen Hindernisse miteinander kommunizieren können und genau
darum geht es ja auch, wenn du jetzt beispielsweise. Alle aus einem Team mit Reinziehst. Ja, also Business owner, ne QA zum Beispiel. Ja, also wirklich Leute die gar nicht eigentlich wo die Implementierung denen gar nicht so wichtig ist.
Es geht denen darum, dass es implementiert ist und funktioniert, ja, dass ihre Anforderungen umgesetzt sind oder das gewünschte Verhalten auch tatsächlich stattfindet, aber denen ist ja egal ob du jetzt ne Serviceklasse da implementierst oder nicht, das ist ja in deiner Verantwortung, das ist ja die technische Seite. Das finde ich auch immer, finde ich auch gut, dass du es sagst, weil genauso haben technische Beschreibungen halt eben zum Beispiel in Stories auch nicht
wirklich viel zu suchen meiner Meinung nach, weil ich finde ne Story wird im Normalfall, zumindest ist das meine Ansicht der Dinge, eben nicht von einem Developer oder ne Developerin geschrieben, sondern halt eben von einer anderen Rolle im Team. Und diese Rolle hat eben gerade auch aus diesen Gründen
vielleicht. Keinen technischen Bezug unbedingt, jedenfalls nicht so krass, oder steckt nicht in der Implementierung drin, weshalb es eigentlich schon schön ist, wenn dann sozusagen diese Story halt eben auch aus dieser Sicht geschrieben wird und eben dann die technische Seite rausgenommen wird und eher die fachliche Seite beleuchtet wird. Was mir noch dazu einfällt, wo ich das gern noch mal ganz kurz abgrenzen möchte, weil wir hatten ja jetzt auch in der
letzten Folge über. DDD gesprochen. Da haben wir auch sehr viel gesagt. OK, wir wollen von der technischen Seite weggehen und wollen das ganze fachlich beleuchten und diese Fachlichkeiten in den Mittelgrund stellen, in den Mittelgrund, in den in den Vordergrund stellen, in den Mittelpunkt Vordergrund sind und. Es ist quasi. Prinzipiell ist es ein bisschen
ähnlich. Es geht darum, wirklich Dinge fachlich zu beschreiben und nicht technisch, nur das ist halt eben der Unterschied ist, dass ddd, ich sag mal die Struktur definiert, also welche Fachlichkeiten hat denn das System, welche Parts gibt es denn da? Und wenn du jetzt aber mit BDD an das ganze Rangehst, dann hast du halt eben. Dass du dir anguckst, welche. Wie verhält sich denn konkret eine Domäne oder eine
Fachlichkeit? Ne, also du definierst das n bisschen runter, du spezifizierst das n bisschen genauer ne, also könnte man jetzt zum Beispiel um das noch mal kurz in einem Satz abzugrenzen, beispielsweise könntest du sagen DDD modelliert was ne Domäne bedeutet Ne und BDD beschreibt wie das System sich aus der Sicht des Anwenders verhalten soll, also die Bedeutung und wie ist die Sicht
des Anwenders auf ja? Und trotzdem teilen Sie sich ja irgendwie diese gleiche Grundhaltung halt auch technisch von. Also das fachliche vom technischen zu trennen. Also es ist halt auch immer spannend, klar, es sind unterschiedliche Bereiche irgendwo, aber sie wohnen entwickelt mit gleichen Grundprinzipien, das find ich halt auch immer spannend dabei. Deswegen, liebe Zuhörer, liebe Zuhörer, falls du die Folge nicht gehört hast und dich das Thema interessiert.
Domain driven Design DDD auch ein super spannendes Thema haben wir auch erst vor kurzem ne Folge zu gemacht. Hör da gerne mal rein. Genau und um dieses ganze ich möcht mal auf nen Thema kommen was wir selbst leben sag ich mal und ich finde das hat gehört hier jetzt auch einfach hin weil es einfach auch wirklich perfekt zu BDD passt. Weil wir bei Tickets schon waren oder Stories. Ja, wie schaffe ich es denn, das ganze fachlich zu beschreiben
oder aus der Sicht des Users? Und da muss ich sagen, so über die Projekte und über die Teams hinweg, in denen ich gearbeitet hab, ist mir aufgefallen, dass das schon nicht einfach ist, das umzusetzen, dass manche Leute Probleme damit haben und immer dazu neigen, schon technische Vorgaben reinzugeben oder schon wirklich zu beschreiben, was zu implementieren ist am Ende. Was ja aber überhaupt gar nicht der Sinn ist.
Und ich meine in dieser No go Folge war das auch ein No go von dir, dass du persönlich das ja gar nicht magst. Wenn jemand quasi dir vorgibt, wie es zu implementieren ist und dann, wenn ich quasi sehr technisch meine Stories beschreibe, lande ich ja automatisch irgendwann da dem Entwickler oder der Entwicklerin, je nachdem wer sich das Ticket zieht, irgendwie Vorgaben zu machen und bin aber
vielleicht gar nicht wirklich. Zu 100% drin in der Software, dass die Personen sich denken, ja warte mal. Nee so, so so können wir das nicht implementieren, das wär nicht gut das so zu implementieren, aber man kriegt halt einfach schon so n so n Blick auf ne technische Seite und der kann ja auch schlecht sein, aber der ist ja erstmal da, das ist ja jetzt erstmal in deinem Kopf was du da gelesen hast, sozusagen ne und davon will man ja wegkommen und wie
schafft man das am besten? Und weil das halt nicht einfach ist, gibt es ja auch verschiedene Techniken dafür einfach und wir persönlich. Sind ja absolut Fan von der gerkin Schreibweise Technik. Ich glaub Schreibweise nennt man es ja, ist ja im Prinzip, dass du sagst ich habe eine feste Struktur um ein gewünschtes Szenario was der Endanwender oder der Kunde der User wie du gesagt hast ne macht und welches welcher Value daraus entsteht. Ne damit ich ganz klar wirklich
ne Geschichte erzählen kann. Nicht es war einmal, sondern die Givenwhen than Struktur. Magst du das vielleicht mal kurz anhand von einem Beispiel erläutern? Ja, also wenn du jetzt zum Beispiel sagst givenwhen zen und ich, also wenn ich jetzt zum Beispiel das nehme, was ich gerade so super technisch mit diesem Warenkorb beschrieben hab, ne. Und ich sag jetzt einfach mal, OK, wir nehmen jetzt eine Anforderung.
Ne, das war ich hatte ja ein paar Fragen hinterher gestellt dazu, also was bedeutet existiert und und diese ganzen Sachen ne gerne noch mal zurückspulen und man nimmt jetzt es ist man kommt ja relativ schnell darauf, dass es mehrere Anforderungen sind, die da irgendwie beschrieben sind und wenn du jetzt zum Beispiel sagst, OK, du hast zum Beispiel ein Szenario was du beschreibst, das Szenario ist neues Produkt wird zum Beispiel hinzugefügt und jetzt beschreibt man das
Ganze mit so, mit dieser gerkin Schreibweise ne given when, denn es gibt manchmal auch noch so n paar Additionswörter wie zum Beispiel End ne, dass du sagst, OK du kannst noch sozusagen eine und Verknüpfung am Ende für das denn zum Beispiel hinzufügen oder wie auch immer. Oder auch für das wenn ne, wenn es jetzt mehrere Bedingungen gibt, ja.
Oder auch das. Und dann könnte es zum Beispiel so aussehen, dass du halt eben sagst Given ne, also angenommen, ein Nutzer hat einen leeren Warenkorb, das heißt du hast auf jeden Fall die aktuelle Situation vor dir, das weißt du. Wenn jetzt ne, also wenn der Benutzer n Produkt in den Warenkorb reinlegt ne klare Sache was da passiert versteht man. Wenn also, dann erscheint das Produkt im Warenkorb so und kann man jetzt noch machen.
Dieses End, was ich gerade meinte, die Menge des Produkts beträgt dann 1 ne so und das ist halt ne relativ ne weil wir weil du ja vorhin meintest, ich konnte nicht so richtig folgen, da ich vermute mal ich geh jetzt mal der Annahme, dass das eigentlich relativ einfach zu verstehen ist. Du sagst OK, du hast irgendwie n leeren Warenkorb, du fügst n Produkt in den Warenkorb hinzu, also hast du quasi dann. Wenn du es vorher nicht hattest, die Menge 1 drin.
Das kannst du jetzt natürlich noch erweitern, dass du sagst okay angenommen du hast einen Warenkorb und du fügst wieder das gleiche Produkt hinzu, was schon im Warenkorb drin ist, dann erhöht sich halt die Menge auf um 2 beispielsweise. Also du hast halt relativ gut eine Beschreibung auf einer fachlichen Ebene, wo man wo gesagt wird, so und so passiert ist wie jetzt genau dein Warenkorb aussieht, was das für eine Klasse ist, was es für Attribute hat.
Oder was für n Service da genutzt wird. Ob du überhaupt n Service nimmst. Ne man weiß ja nicht wie diese. Also man sollte eigentlich nicht davon ausgehen, dass man weiß wie diese Software darunter zugrunde liegend aussieht. Ja dieses Wissen braucht man doch gar nicht, kann man das ganze Ding so implementieren und was ich an dieser gerkin Schreibweise super super geil finde ist, dass selbst wenn du zum Beispiel egal wer jetzt
diese. Diese diese Story sag ich jetzt mal abnimmt oder mal prüft und guckt ob es funktioniert, kannst du genau diese entsprechenden Schritte dir einfach sozusagen nachstellen? Ne, also du kannst zum Beispiel gucken, OK warte mal, ich brauch n Warenkorb der leer ist.
OK hab ich passt ne dann kannst du es einfach so wirklich durchprüfen und kannst dann einfach sagen OK wenn ich das Hinzufüge, dann hab ich danach ein ein Produkt drin OK passt auch super OK die Story scheint wohl zu funktionieren so nach dem Motto Ne und dann brauchst du aber nicht zum Beispiel wirklich zu gucken. Weiß ich nicht. Wurde denn jetzt tatsächlich das technisch so umgesetzt, wie es
in der Story steht? Da musst du vielleicht irgendwie noch in den Code gucken, obwohl du ja eigentlich mit dem Code vielleicht gar nichts zu tun hast, weil du keine Ahnung product owner bist oder sowas ne und nicht developer beispielsweise. Ja und was halt auch cool ist, an der Schreibweise ist, dass du ja also genauso wie du es gesagt hast ne, also ich definier n Szenario.
Warum also das ist ja das warum, warum mach ich etwas ne ich hab n Szenario, das möchte ich erreichen, ich möchte etwas in den Warenkorb legen wie du jetzt als Beispiel genommen hast. Ne das ist so mein Szenario. Und beschreibe. Denn, was passieren soll und was am Ende das Ergebnis ist. Und genauso kann ich ja jetzt viele Szenarien so aufbauen, ne, dass sie sozusagen den Titel haben, was so n bisschen das warum abdeckt, ne, dass man einfach mit einem Satz oder mit
einem Schlagwort lesen kann. Ah OK, darum geht es in diesem Szenario, dann nehm ich die gerkin Schreibweise und das Gute ist es ist ne übungssache Ticket so zu formulieren, weil es am
Anfang schwer fällt. Und das ist halt genau der der Knackpunkt dabei, was ich so witzig finde ist, wenn es schwerfällt, das was du gerade vorhast in diese Schreibweise zu bringen, kann es sein, dass es vielleicht gar nicht so richtig user Value liefert, an der Stelle weißt du mal provokativ gesagt, also wenn ich es nicht formulieren kann, dann fällt es mir ja scheinbar schwer das warum zu definieren, warum mach ich das gerade eigentlich, warum soll das jetzt in die Software?
Leicht, provokativ, klar, es gibt auch, man hat auch Tickets Chance oder so wo man sagt, EY wir müssen mal was umbauen, wir müssen mal was refact dann oder so ne es geht aber jetzt so sag ich mal um Features um Stories ne die jetzt wirklich neue Sachen mit reinbringen. Ja, zum Beispiel kannst du ja einfach dir überlegen, OK, es ist ne vielleicht n refactoring, das heißt du änderst was an deiner Infrastruktur.
Veränderst aber nicht die Funktionalität oder kein Value der irgendwie, also der der User Value verändert sich nicht, weil der User benutzt das trotzdem noch genauso wie vorher ne veränderst ne andere Datenbank was auch immer ne, aber am Ende ändert sich für den User trotzdem nichts. Ne das wäre zum. Beispiel N Shore. Oder n Bug. Ich finde das sind Dinge, die kann man auf jeden Fall technisch beschreiben, aber halt
eben nicht die. Guten Bug kannst du natürlich auch in der Schreibweise oftmals unterbringen, als ist das möglich. Auf jeden Fall aber nur um das klar. Also danke für den Hinweis, um das halt einfach mal n bisschen zu differenzieren, dass wir hier natürlich von User Value von neuen User Value sprechen, ne?
Und genau, und jetzt ist die Frage ne, ich mach jetzt so mehrere Szenarien, ich kann das runter definieren wie du meintest, jetzt kann jemand das nehmen der nicht in der Software drin steckt in die Implementierung ja also der ist nicht implementiert und ist trotzdem in der Lage es theoretisch testen zu können. Ja. Ja, also manuell zum Beispiel, indem man einfach sich auf die
Website geht. Die Applikation startet, das einfach ausprobiert, je nachdem, welches Projekt das jetzt ist, ne. Und das finde ich halt. Das coole an BDD, dass du sagst, lass uns doch mal, bevor wir hier irgendwie über implementieren, testen oder irgendwas sprechen, mal wirklich.
Erst das Verhalten klären, genauso wie wir es ja gerade gesagt haben und das in so nen Ticket zum Beispiel ist jetzt nur n Beispiel ne wo du es hinschreibst darum geht es nicht ne also du kannst es von mir aus auch in ne Textdatei speichern und einchecken für den nächsten, aber jetzt gehen wir mal davon aus du hast jetzt n Ticketsystem oder irgendwas Fakt ist du definierst das verhalten was du möchtest das warum warum soll
das jetzt passieren? Die Szenarien sind eigentlich irgendwo ja auch Beispiele. Ne also Beispiele wie das Ganze passieren soll, dass dieser User Value entsteht. Du hast jetzt die Sicht des Users und guckst da drauf und denkst dir so was will ich machen in der Situation ja ich möchte es hinzufügen ja aber warte mal. Vielleicht hab ich ja was Falsches hinzugefügt, da möchte ich ja auch wieder Sachen wegnehmen können und so und du fängst halt an es aus user Brille zu sehen.
Und machst dir über die ganzen Cases, ja über die verschiedenen Möglichkeiten viel mehr Gedanken und schreibst sie halt genau in dieser Schreibweise runter, sodass jetzt jemand das abtesten kann. Und BDD geht ja jetzt deswegen auch als Zusatz zu TDD und jetzt kommen wir mal so n bisschen in die Testingwelt BDD sagt OK, jetzt haben wir diese ganzen Szenarienbeispiele. Aber die möchte ich natürlich jetzt auch automatisiert in Tests Gießen. Ja, also automatisiert im Sinne von.
Die Tests können automatisiert laufen, nicht dass jetzt irgendwie aus Zauberhandtests daraus entstehen. Ja, also wir sind jetzt hier nicht mit irgendwie KI unterwegs, sondern einfach dass quasi. Diese Beispiele, Szenarien, die Tests dazu auch automatisiert laufen können. Und das ist halt n super cooler Ansatz, der jetzt mit TDD verschmilzt, sozusagen, dass man sich jetzt zum Beispiel n givenwhen zen Szenario nimmt
und. N Test schreibt Ja und da bildest du das jetzt ab. Jetzt gibt es so verschiedene Tools die da oder Frameworks die das unterstützen, dass du halt wirklich so annotations hast wie Given when denn und dann werden die entsprechenden Funktionen da drunter aufgerufen und dann hast du das so ganz Fancy. In dieser Struktur, muss aber
nicht sein, du kannst. Das ist nämlich das wichtige bei das ist n Prinzip, das ist ne Strategie, das ist kein kein Tool, kein Framework im Sinne von dann musst du jetzt auch keine Ahnung Lizenz XY kaufen um BDD machen zu können.
Ja das noch mal ganz klar gesagt, du kannst jetzt auch keine Ahnung, wir nehmen ja zum Beispiel auf, just wenn wir irgendwie auch auf Twitch was coden, du kannst jetzt auch n ganz einfachen Unit Test mit just anlegen und trotzdem dieses Szenario da abbilden und im Endeffekt ist das ja auch.
Beispielsweise in unserem Beruf. Ja, wir sind ja im selben Team wie wir auch implementieren aktuell ne, dass wir die Tickets gerne so hätten, wenn wir sie selbst schreiben, schreiben wir sie so, wir können nicht immer beeinflussen, wie sie von außen kommen, ja, aber wir sind halt Fans von der gerkin Schreibweise, weil man daraus wirklich gute Tests auch schreiben kann und da wir nach TDD arbeiten oder so n Mix aus
BDD und TDD ja machen. Sind wir ja froh, diese Tickets zu haben, weil es sich gut in Tests gießen lässt, um dann daraus resultierend zu implementieren. Du hast ja im Endeffekt genau du. Du kannst ja theoretisch, weil so n ich sag mal so ne given when, denn kann man ja auch als Anforderung sehen. Innerhalb also als eine Anforderung zu einem Feature zum Beispiel oder zu einer Story beispielsweise ne.
Genau kann man ja so sehen, kann man ja dann auch direkt so in eine in den Test gießen wie du meinst. Ich hab zum Beispiel auch mal gehabt, da hat n mein Kollege zum Beispiel n alter Kollege von mir, der hat das, der hatte mal n Kommentar drüber geschrieben, ne given, dann hat er was den Code gemacht, da in dem Test und dann when und dann then.
Ich find zum Beispiel muss man nicht unbedingt machen, weil man sich irgendwie diese Kommentare sparen kann, weil im Endeffekt kommst du gar nicht drumherum, dieses Givenwhen denn irgendwie Prinzip anzuwenden, weil dein Given sind ja im ersten Mal so irgendwie, sagen wir mal bestimmte Klassen oder beziehungsweise Objekte von Klassen, die du dir irgendwie erstellst für dein Testszenario ne. Also was brauch ich, was ist denn aktuell da zum Beispiel?
Du stellst irgendwie n Warenkorb der leer ist beispielsweise ne. Und hast dann zum Beispiel sowas wie du nimmst halt deine dein, also deinen Warenkorb und machst n at drauf oder deinen Service machst n at mit einem bestimmten Produkt, was du dir auch im
Given angelegt hast. Ne, das heißt du hast im Endeffekt irgendwie sowas wie gegeben, Lern Warenkorb und irgendwie n Produkt und dann sagst OK füg das Produkt da hinzu, das ist dann dein denn und dann dein Expect am Ende zum Beispiel oder wie du es nennen magst ist dann im Endeffekt das das denn ne. So und manchmal finde ich es auch ganz angenehm, wenn man dann vielleicht so einfach logisch ne Leerzeile in die Tests einbaut.
An den Stellen hast du zum Beispiel gesagt, zwischen Given ran und dann immer mal ne Leerzeile rein, dann hast du es ja optisch n bisschen geclustert, wie gesagt, n alter Kollege von mir hat das halt halt mit Kommentaren dran geschrieben, kann man auch. Machen ja, hab ich auch schon öfter gesehen, finde ich nicht schlimm, ich selbst mach es, mach es auch nicht, aber ich ich sag mal das ist.
Das ist OK, das sind nicht, das sind nicht so böse Kommentare, wie wir sie ja schon öfter mal erwähnt haben, sondern das ist OK so, das kann man machen, ne, wenn das einfach optische Struktur noch reinbringt, genau. Aber zum Beispiel auch gerade, wenn man sich jetzt also für mich, ich finde mal das häufigste ist dann so n Argument zu sagen, ja gut, aber was ist denn, wenn du zum Beispiel n Fall vergisst?
Also ne Anforderung in deiner gerkin Schreibweise in deiner Story. Da denk ich mir immer so. Ja du kannst bei TDD auch n Fall vergessen und wenn du zum Beispiel sagst, OK du machst TDD mäßig, wirklich nur das was du in deiner Story zum Beispiel drin hast. Was so behavior driven sag ich jetzt mal definiert wurde und du denkst nicht mehr mit und versuchst es einfach nur n Test
abzubilden. Das ist natürlich blöd, man sollte natürlich immer mitdenken, also zu von dem Schritt ich sag ich nenn es jetzt einfach mal von BDD zu TDD rüber, sollte man natürlich immer noch mitdenken, es ist nie verkehrt das zu tun, aber genau. Du kannst immer was vergessen und ich finde es halt immer so lustig. Klar, du kannst immer irgendwas vergessen, aber und das ist doch genau der.es ist doch auch noch keiner, also kein Meister vom
Himmel gefallen, also wie? Wieso erwartet man wenn man sagt ja wir machen das nicht, weil das ist irgendwie zu kompliziert oder man vergisst da was oder man kriegt das nicht richtig hin. Kann man sich natürlich so hinstellen, aber so würde man ja glaub ich gefühlt im Leben nie was auf die Reihe kriegen, wenn man nicht sagt, OK, ich kann es nicht, also lass ich es so. Nein ich kann es nicht, also lern ich es, weil es sinnvoll ist. So das ist finde ich immer eher dann die Herangehensweise.
Ja und Fehler passieren halt einfach ne also. Das ist ja nur nur das, das das braucht man ja nicht diskutieren, das ist einfach so. Die Frage ist ja eher, welche Strategien kann man anwenden, ne um einfach bestmöglich das umzusetzen oder so wenig wie möglich Fälle zu vergessen und wenn man jetzt so n ganz klassisches TDD von BDD noch mal so n bisschen unterscheiden möchte, ne ganz klassisches TDD sagt ja eigentlich nur wie wir vorhin meinten.
Teste, bevor du Implementierst, zeigt, dass es nicht geht, implementiere es und dann geht es und refector noch mal so. Das ist ja aber auf einer, sagen wir mal, hier sind wir jetzt so auf Unit testebene ist das natürlich sehr technisch, ne, das kann jetzt auch einfach sein, dass ich ne kleine berechnungsfunktion hab, die irgendwo verwendet wird und die teste ich ab, dann schreibe ich meinen Test. TDDE funktioniert nicht, implementiere OK, das funktioniert. Schreib den nächsten Test.
Ja, aber bei der Berechnung funktioniert es nicht richtig, ah OK zwoter Test pass meine Implementierung an beide Tests noch grün und so weiter klassisches TDD ist ja aber wirklich im Endeffekt nur wie funktioniert diese Funktion? Ich schreibe Tests die beschreiben wie diese Berechnungsfunktion funktioniert. Ja. Ja, also ich bin auf sehr
technischer Ebene unterwegs. Das ist das ganz klassische TDD, wie wir jetzt zum Beispiel im Berufsalltag arbeiten, geht ja schon mehr in die BDD Richtung, ja, dass wir jetzt nämlich sagen, Na, wir testen jetzt aber nicht nur TDD, technisch das technische so kleine Funktion ab, sondern wir überlegen uns, und da helfen jetzt die Tickets. Warum mach ich? Warum brauch ich diese berechnungsfunktion, wo brauch ich diese Funktion, warum muss die überhaupt da sein?
Ne ich kann ja jetzt alles in kleinsten Bestandteilen abtesten OK, aber das gewährleistet nicht, dass das große warum dahinter beantwortet ist. Also fang ich ja auch an TDD zu nutzen mit dem Input der durch Behavior Driven Development entsteht so meine Tests aufzubauen und dann bin ich halt bei dem Givenwand zum Beispiel. Ja ne was du meintest, es geht ja auch nicht das warum beantworten.
Geht ja auch schon mit dem Testnamen finde ich los, den kann man auch rein theoretisch schon sehr fachlich beschreiben, muss ihn nicht unbedingt technisch beschreiben. Wenn du jetzt zum Beispiel sagst, OK, es wird ne Exception geworfen, ne, dann musst du das nicht. Im Test kannst du machen, kannst sagen es wird ne Exception geworfen. Wenn das und das passiert.
Du kannst natürlich aber auch sagen, dass es irgendwie failed oder so ne oder irgendwie anders anderweitig beschreiben, dass du nicht sagst, OK, es ist ne Exception, rein theoretisch kannst du verschiedene Art und weisen auf verschiedene Art und Weisen darstellen, dass etwas failed. Entweder du wirst ne Exception oder du gibst ne -1 zurück, je nach Kontext am Ende, aber das ist genau der Punkt.
Auch, weil wir manchmal gesagt haben oder weil wir gerne sagen, Tests dokumentieren auch die Software.
Je fachlicher sie geschrieben sind oder die Titel der Tests sind, desto besser dokumentieren sie eigentlich auch deine Software, ohne dass du technisch genau sagst, es muss jetzt eine Exception geworfen werden oder halt nicht oder was auch immer, ja. Jetzt ist die Frage auch mal so in deine Richtung. Ne, jetzt haben wir so n klassisches TDD mal gesagt, so NBDD als Aufbau oben drauf rum, was ja so das Kernthema heute ist.
Ne heißt das entweder mach ich solche Tests oder solche Tests oder ist es irgendwo auch n Mix am Ende also sind das jetzt so ganz starre Struktur, ich weiß es so so so n bisschen rhetorische Frage gerade, aber ich möchte das einfach noch mal ganz klar sagen, ich möchte, dass du das noch mal ganz klar sagst. Das geht doch beides, oder?
Ich bin raus. Nein, also ich denk mir also für mich ist es eigentlich so, dass auf je höherer, also je höher deine Ebene ist, auf der du Testest, desto mehr solltest Behavior driven sein, sag ich jetzt mal oder desto mehr sollte denn auch das ganze fachlich sein und je tiefer du kommst, also je wirklich. Je tiefer du auf ne. Wenn du jetzt zum Beispiel du hast ne utils Klasse ne die irgendwie dieses klassische utils Ding ne, ja wo du eigentlich dir. Denkauffanglager auffang weg.
Aber da kann sich ja jeder was drunter vorstellen. Aber an dieser Stelle, beispielsweise wenn du da irgendwie ne bestimmte Funktion abtestest wie willst du irgendeine Fachlichkeit da reinbringen, die aber überhaupt nicht wirklich fachlich ist? Ne, jetzt noch mal domain driven design in in domain driven design gesprochen. Das ist ja, das gehört ja auch zu keiner, zu keiner Domain dieses Utils, weil es wird irgendwo verortet, was überall
verwendet wird. Es ist also quasi keiner Fachlichkeit zugeordnet, demzufolge, wenn du es in keiner Fachlichkeit zugeordnet hast, wie willst du es dann irgendwie, ich sag mal fachlich beschreiben, du kannst es eigentlich nur technisch beschreiben oder eher technisch beschreiben, ne, so solche utils Dinger und genau das ist finde ich so das Ding, also auf je höherer Ebene man unterwegs ist.
Zum Beispiel du bedienst ne UI irgendwie im Browser irgendwas, da kannst du super entspannt sagen, wenn du dies machst und das machst, dann passiert das und das also ne, also zum Beispiel dieses Shopping Card Ding Beispiel das kennt jeder irgendwie irgendeinen E Commerce Shop, das kannst du perfekt damit abtesten auf Systemebene beispielsweise, aber wenn du irgendwo ganz unten bist wie gesagt dann.
Wird es halt irgendwann super technisch und dann kommst du aus dieser technischen Seite auch gar nicht mehr raus. Aber es ist dann auch nicht schlimm, weil du ja wie gesagt technisch unterwegs bist und nicht fachlich überhaupt nicht. Ja, ja oder n anderes Beispiel. Nehmen wir einfach so ne Login Page, ja die begegnet dir 5000 mal am Tag und dann kannst du halt einmal BDD ne Story haben die sagt wenn ich auf der Login
page bin. Und ich gebe ne valide Username und Passwort ein und drück auf Login. Dann bin ich eingeloggt, so nach dem Motto, ja das wär jetzt so ne ganz simple Story die jeder versteht und da ist jetzt egal wie der Login passiert oder was ob da überhaupt n richtiger Login stattfindet oder du einfach weitergeleitet wirst. Ja also bei dieser Story ist das ja erstmal egal und trotzdem kann ich unter der Haube zum Beispiel wenn Username irgendwie
ne e Mail sein soll, also. Der Account nehmen, denn zum Beispiel ist ne e Mail und ich hab da so n validata für ne e Mail. Ja wie kann das überhaupt aussehen? Dann bin ich halt so technisch, dann schreib ich halt keine User Value Test sondern ich teste einfach in zig Cases ab ob er richtig erkennt ob das ne valide e Mail ist oder nicht um da jetzt noch mal so beide Hierarchien zu zeigen, ja und das eine hat halt User Value und ist Behavior Driven und das andere ist Test driven um
einfach zu gewährleisten. Dass bitte jede valide E Mail auch erkannt wird. Ja, aber das find ich ganz gut, weil das Match irgendwie wieder weil am Ende ist. Zum Beispiel so n so n ich nenn es mal jetzt e Mail validata ne oder validate Mail was auch immer, wenn du das zum Beispiel in so einem utils verortest, weil es an verschiedenen Stellen irgendwie gebraucht wird, dann ist es halt eigentlich nur
wichtig. OK ist das irgendwie ne valide Mail oder nicht so ne und dann kann man es halt wie gesagt auch dann ist es technisch. Gut, dass man es technisch halt eben beschreibt, weil es halt auch technisch ist. Ne, also cooles Beispiel, auf jeden Fall genau. Und jetzt ist ja aber irgendwo so n bisschen die Frage, was ist
denn das Ziel dahinter? Ne, also das würde ich auch noch mal gerne n bisschen herauskristallisieren, weil wir sind ja auch wirklich Verfechter gerade vom TDD, wir nennen es jetzt nicht so unbedingt, dass wir sagen, ja, wir arbeiten nach BDD ja, also wir, meistens reden wir ja von Test driven Development und im Endeffekt. Nehmen wir vieles von Behavior Driven Development und setzen das bei uns auch in Top. Ja, aber was sind so grob die Ziele dahinter?
Ne, weil man kann sich jetzt fragen, ja OK, klingt alles irgendwie ganz cool, klingt aber auch irgendwie nach ziemlich viel Overhead. Ich könnt ja auch einfach loslegen so ne, aber was erhofft man sich oder was sind so die Benefits davon das das muss man muss man ja auch einfach mal klar herauskristallisieren. Ja, das ist so ein bisschen
ähnlich wie bei DDD. Also du hast halt eine klare Kommunikation, also du weißt halt am Ende, wenn du über irgendwas sprichst, wie wäre es ja schon wie du, du hast es am Anfang eingehend super geil gesagt, ich habe es jetzt irgendwie technisch irgendwie was zusammengeschustert und du so ich kann, ich weiß jetzt schon gar nicht mehr was du gesagt hast und irgendwie konnte ich dir auch zu dem Zeitpunkt gar nicht folgen, aber wenn ich es dir sozusagen fachlich
beschrieben hätte, dann wäre es super klar gewesen, das hättest
du wahrscheinlich also. Das, was ich dir vorhin sozusagen dieser Szenarien und gerkin Schreibweise sozusagen so als Story erzählt hab, so, das hast du wahrscheinlich immer noch im Kopf und das ist genau diese Art von Kommunikation, die du dann am Ende Halt hast, die einfach, das ist einfach klar was passiert und ich finde, genau das ist ja auch das Wichtige dabei, du hast unterschiedliche Rollen im Team und jeder muss über das Gleiche sprechen, aber am Ende sozusagen
der Rattenschwanz under the Hood, was dann da? Unten drunter hängt, da kümmert sich dann halt jeder einzeln drum ne. Also wenn du jetzt als Entwickler weißt du was was gemeint ist und du musst es entwickeln so und was weiß ich als wenn du jetzt irgendwie Marketing Chef bist oder was auch immer, dann weißt du auch was gemeint ist. Aber du musst ja trotzdem irgendwie gucken wie du es vermarktet kriegst ne also es sind halt unterschiedliche Dinge wie du aber und du musst in
deiner. In deiner Welt dann damit umgehen können, aber die gemeinsame Sprache haben, das heißt, es ist halt einfach n kommunikationsding, was super wertvoll ist. Na ja, und ich sag mal, dadurch dass du ne Basis hast, auf der du kommunizierst, wirst du auch sehr sehr wahrscheinlich weniger böse Überraschungen haben.
Am Ende ne. Sowohl für Stakeholder als auch für den Coder, der jetzt wochenlang implementiert, mal übertrieben gesagt, Ey Leute nicht so große Tickets, ne, aber jetzt war in unserem Beispiel wochenlang implementiert und dann heißt es auf einmal. Ja, nee, das ist doch überhaupt gar nicht, was wir wollen. Also wir haben doch ganz, ganz dolle technisch 5 Minuten darüber gesprochen, es muss doch absolut klar sein, was gewollt war.
Ja nee, sorry, also hab komplett in ne andere Richtung gedacht, ja und weniger Überraschung kommt natürlich dem Projekt einfach zugute, ne, weil einfach Features die dann am Ende implementiert werden auch wirklich echten Nutzen haben.
Ja also wir beide, das ist doch gar nicht so lange her, vielleicht n Jahr oder so. Da haben wir beide ja auch an einem größeren Feature gearbeitet, was man uns quasi erklärt hat, dass das wichtig ist und hier und da, und dann haben wir da ewig rumimplementiert und das war n absolutes Chaos, wo wir uns auch dachten, Leute, was geht hier eigentlich ab und am Ende fragen wir uns bis heute, was jetzt wirklich der User Value dahinten war dahinter war oder ob das nur
gefühlt einer Person geholfen hat. Und das ist glaub ich auch wichtig, weil gerade diese Art und Weise sozusagen Software zu entwickeln beziehungsweise die diesen Ansatz zu fahren. Du versetzt dich viel mehr in das in das hinein, was eigentlich am Ende gewünscht wird, was es eigentlich soll, was wirklich, wirklich wichtig ist, ne was so reale. Szenarien sind einfach ne und nicht nur so n so n absoluter Sondercase, der einmal in 1000 Jahren auftritt so. Du verhaspelst dich halt nicht
so krass. Was ja auch irgendwie dann am Ende bedeutet, du brauchst weniger oder machst vielleicht auch weniger over Engineering, weil du halt gar nicht n riesen Konstrukt möglicherweise brauchst, von dem es halt, was eigentlich gar nicht gewünscht ist, was dann auch wieder dazu führt, dass zum Beispiel im Normalfall dann auch weniger Bugs irgendwie hast, die dann auftreten, ne und ja, das ist ne Sache, ich mein das haben wir schon oft genug gesagt, aber die
Dokumentation, die allein schon über die Tests.
Also du hast ja auf verschiedenen Art und weisen ne Dokumentation. Du kannst in den Stories supergeil nachlesen, OK was passiert hier eigentlich, was macht das eigentlich, das sind es ist natürlich Dokumentation ist noch mal n eigenes Thema für sich, weil Dokumentation findet auf verschiedenen Ebenen statt ne das ist ja Software Dokumentation der Software Dokumentation der Anwendung für den Anwender beispielsweise Dokumentation für was weiß ich
ich sag mal aus PO sicht ne so in die Richtung du hast ja Dokumentation auf verschiedenen Ebenen aber.
Einige Arten von Dokumentationen sind halt einfach schon so Low hanging Fruits dabei, dann ne ja und es hilft natürlich auch diese Dokumentation. Wenn du jetzt Wochen später also auch für dich selbst ja der das entwickelt hat, ist es für dich auch ne Dokumentation, wenn du Wochen später drauf guckst und nicht mehr weißt, wie es wirklich funktioniert hat und du dann anhand solcher Schreibweisen oder gut benahmten Tests sofort wieder weißt, was da abging.
Ich mein, das beste Beispiel kann man ja einfach mal aus unseren Twitch sessions nehmen. Wir haben ja nen eigenen Chatbot geschrieben, so war so Community Wunsch. Ey lass mal machen, klar der kann nicht so viel wie von weiß nicht streamlabs oder was nutzen die meisten, das ist ja so n ultimativer Overbot der einfach alles kann so ne unser nicht, aber dafür ist er witzig von uns geschrieben aber trotzdem gab es schon so oft den Moment wo wir uns dachten.
Boah, wie sehen denn noch mal diese Twitch messages aus, die wir da empfangen? Wie sieht denn das noch mal aus? Und anstatt wieder die ganze Doku durchzukramen, gucken wir einfach in die Tests rein und sehen einfach aha, wenn ich das mache und hier und dann kriege ich das und das erwarte ich so
mal. Jetzt ganz einfach gesagt, du kannst da einfach reingucken und weißt sofort, ah so sieht es aus, du weißt hoch auf dein Test auch genau und kannst es dann einfach schnell wieder reproduzieren und das ist halt auch n riesen Benefit. Den, den ich anfangs unterschätzt hatte, wo ich mir dachte, ja OK, Dokumentation ja OK, wir haben Tests, die haben Namen, ist ja in Ordnung, aber es hilft dir im Nachhinein unglaublich, wieder in solche
Themen dann wieder einzusteigen, gerade wenn es auch schon n bisschen älter ist und noch so mantained werden muss. Ja, auf jeden Fall. Ich meine, man muss natürlich sagen, klar hast du Herausforderungen irgendwo bei der ganzen Sache. Weil du musst.
Die musst dich natürlich irgendwie, also du musst dich irgendwie einarbeiten, du musst gedanklich erstmal da reinkommen, dass man sich denkt, na ja, OK, wie geht das jetzt noch mal ne also gerkin Schreibweise, was auch immer wie wie formulier ich das am besten und ich hab das auch manchmal, dass ich mir denke so man kann sich ja hinstellen und sagen ich bin Entwickler, ich möchte gerne, dass das so gemacht wird und wenn ich da selber zum Beispiel mal darüber nachdenke
und sage, OK, wie würde ich denn sowas beschreiben, denk ich mir auch manchmal so. Gar nicht so einfach, unbedingt ne und klar ist es nicht immer einfach, wenn man was Neues macht. Wie ich schon meinte, aber es lohnt sich halt am Ende ne und da finde ich ist es halt einfach ne gute Gelegenheit. Man kann ja auch nur besser werden und ich denk mir so selbst ne.
Gerkin Schreibweise einer Story meiner Meinung nach ist immer noch besser als irgendeine technische irgendwas wulst e Mail reinkopiert so und so soll es werden. Mach mal bitte und dann hast du irgendwas wo du denkst OK ich hab 1000 fragen ne wo du aber im Endeffekt wirklich mehr darüber versuchst nachzudenken was eigentlich wirklich gemacht werden soll, was überhaupt nicht aus Usersicht.
Irgendwie dargestellt ist, sondern eher so aus technischer Insider Sicht sag ich jetzt mal ne, das ist dann irgendwie Käse, also klar Overhead, neue Gedanken, neue Sichtweise, aber ich würd sagen es lohnt sich dennoch. Auf jeden Fall. Natürlich bringt es nicht nur Overhead mit sich, sondern auch wie jede Strategie ne, nichts
ist perfekt. Oder nichts ist für jedes Team geeignet oder für jedes Projekt. Man muss halt immer differenzieren, bringt es uns in unserem aktuellen Projekt was oder nicht, deswegen würde ich gerne ja das ganze noch mal so n bisschen durchspielen mit dir, wie man jetzt quasi. Ja, wie Havia Driven Development betreiben kann.
Wir haben ja eigentlich jeden Punkt besprochen, ich würd es gerne noch mal n bisschen zusammenfassen, so als kleiner Überblick und aber dann speziell mal auf unsere Sicht der Dinge eingehen. Was ist der Vorteil jetzt dabei und was ist ne Herausforderung, die wir vielleicht auch selbst da einfach schon erlebt haben, weil man muss ja fair sein wir es ist jetzt nicht der heilige Gral so ne wie alles, so jede Strategie die wir oder designen was wir besprechen.
Und deswegen würd ich einfach mal starten.
Ne, Wir haben ja gesagt es geht darum ne klare Kommunikation zu fahren, ne und wenn man jetzt so das ganz prozesstechnisch betrachtet so Lehrbuchhaft wie du immer sagst beginnt halt BDD genau da und man sagt man hat so ne Discovery Phase ne dass man sagt wir sorgen jetzt erstmal dafür, dass wir n gemeinsames Verständnis haben, ne dass alle verstehen worum es geht und warum wir das machen und das find ich ist ne sehr ist n sehr wichtiger Schritt, den haben wir ja auch schon jetzt wirklich.
Viel besprochen, aber noch mal ganz kurz. Was ist eigentlich das Problem, was wir lösen wollen? Was will der User von uns? Das sind so die Fragen, die man da klären muss auf einer allgemeinen Sprache und dieser Schritt ist so essentiell, warum ich es jetzt noch mal explizit anspreche, wie oft lesen wir in der Community oder bringen wir auch selbst in die Community rein, das ist so echt top. 3 der Probleme könnt es sogar auf Platz 1 sein, aber es ist mindestens top 3 würde ich sagen.
Sind. Man fühlt sich als Entwicklerin oder Entwickler einfach Lost, weil Anforderungen einfach nullklar sind. So richtig schön unklar, man weiß eigentlich gar nicht, was genau zu tun ist.
Man entwickelt erstmal, weil man muss ja vorwärts kommen, man hat Projektdruck und am Ende ist es vielleicht auch noch komplett falsch und muss noch mal von vorne anfangen und genau mit dieser Discovery Phase. Sorgt BDD dafür, da Struktur da wirklich endlich mal Struktur reinzubringen und zu versuchen, genau nicht mehr in diese Falle zu tappen?
Ich finde, wenn man das jetzt so in den Arbeitsalltag integrieren würde, zum Beispiel agiles Framework, hast du halt genau den Punkt. Jemand schreibt diese Stories. Und die werden dann zum Beispiel im Refinement einfach noch mal durchgegangen. Das heißt, du also, da wird ja quasi im ganzen Team noch mal besprochen, was ist denn jetzt eigentlich der User Value, welche Probleme haben wir denn eigentlich und ist es überhaupt sinnvoll, das Ganze zu machen?
So, und dann kannst du genau das an dieser Stelle adressieren, so dass es für mich zumindest irgendwie diese Discovery Face ne gehört irgendwie so n bisschen mit da rein, also so im ja, ich sag mal in in in den in den echten Arbeitsalltag integriert, ne. Ja, ja, das verschmilzt ja auch. Du hast ja dann im Lehrbuch noch so ne formulation Phase, so als zweites ne, das verschmilzt halt irgendwo dann.
Aber wichtig ist, dass man diesen Inhalt versteht dieser Phasen und die lebt sozusagen, weil du jetzt meintest Refinement. Jetzt kann ja jemand sagen hä laut Lehrbuch schreiben wir jetzt aber erst ja die Tickets in gerkin Format ja OK, ist alles gut, beruhigen wir uns
alle mal wieder. Aber im Prinzip sind das so die Phasen, ja, und die Phase 2 sagt jetzt, jetzt schreiben wir das Ganze, diese Szenarien, wir haben jetzt da drüber gesprochen, wir wissen, was es für Szenarien gibt, und die werden jetzt quasi genau in dieser einheitlichen Sprache aufgeschrieben. Ja, und dann so gut lesbar für alle, damit mein ich nicht die Schriftgröße oder so, sondern halt, dass es so fachlich ist, dass jeder es versteht, ja und
und so gut und. Deswegen, das ist n Punkt muss ich sagen, nutzen wir super gern für unsere Tickets. Also diesen Schritt wirklich ausführlich zu machen und zu sagen mit dieser Schreibweise Wir sind dran gewöhnt wir diese Buzzwords. Ja man schreibt die ja auch oft so capslock, dass du sagst given when when und du kannst einfach.
Sag ich mal. Tickets unfassbar schnell scannen und wenn du jetzt zum Beispiel von einem Refinement sprichst, wo nicht jeder auf dem Schirm hat, um welches Ticket es gerade geht, dann kriegt jeder seine Minute und danach ist klar, worum es geht und dann kann man zusammen noch mal drüber sprechen. Genau, und das ist so ein riesen Benefit am Ende. Und das ist genau wichtig, weil du einfach sofort verstehst, was da passieren soll. Und es geht nicht um die technische Seite.
Scheiß auf die technische Seite, es geht nur darum was was was ist eigentlich gewollt so. Fertig. Genau. Und das ist auf jeden Fall
wichtig. Ja, und dann, wenn du jetzt schon bei den ganzen offiziellen Phasen bist, kommt ja die Automation Phase wo du dann sagst, OK, du hast jetzt vielleicht irgendwie Tools wie zum Beispiel Cubecome habe ich noch nie mitgearbeitet, bietet sowas was du vorhin meintest auch mit so einer gärkchen Schreibweise oder wie wir es vorhin besprochen haben und dann gießt du halt eben die entsprechenden Anforderungen, die du irgendwie in der gärkchen
Schreibweise von deiner Story hast, in die entsprechenden Tests und hast die dann halt sozusagen einmal. Ja und? Dann sind wir so in dem tdd Zyklus am Ende genau genau. Kann man so sagen, ne, also du
hast denn natürlich ich. Also ich hab jetzt meine Tests, die daraus resultieren wie du meintest ich implementier sie sehe, dass sie erfolgreich sind, hab denn im Prinzip auch meine Schleifen wieder meine Feedback und Factoring schleifen und zieh das dann so durch bis es abgeschlossen ist bis ich sage jetzt ist es sag ich mal stabil ne also jetzt ist der Userwunsch umgesetzt und funktioniert genauso wie der User sich das wünscht nächstes Ticket nächste Story ja dann ist das
abgeschlossen. Genau, aber ich würd gern noch mal so auf n paar Herausforderungen eingehen. Würdest du sagen es gibt aber Projekte wo es keinen Sinn macht? Es gibt immer irgendwie was, wo es keinen Sinn macht würd ich sagen. Es sind 99% der Fälle oder also es ist halt, es ist halt oft so. Es ist natürlich, wenn du wie wir auch bei DDD schon gesagt haben, je komplexer irgendwas ist desto mehr Techniken.
Bräuchtest. Das heißt, wenn du jetzt aber zum Beispiel sagst, du hast kleine Projekte oder du hast zum Beispiel, Du entwickelst eine Library, die zum Beispiel sehr technisch ist, wie willst du da großartig fachlich werden, so als Idee ne oder zum Beispiel, du willst irgendwie so Proof of Concept machen und Prototyping, ein MVP schnell irgendwie rausballern, dann hast du halt einfach ein anderes Ziel dahinter einen anderen, ich sag mal n anderen Purpose der
dahinter steckt und dann brauchst du jetzt nicht unbedingt mit BDD anfangen, heißt aber nicht, dass man es komplett gar nicht machen sollte, oder vielleicht sag ich mal TDD, wenn man jetzt zum Beispiel trotzdem aber ne gewisse, Ich sag mal Sicherheit für seine Software haben möchte, kannst du ja trotzdem irgendwie das ganze so ich sag mal so ne Art Mischmasch ne oder so n Ansatz da zu fahren, aber es wie gesagt es lohnt sich nicht immer den kompletten.
Wurf da drauf zu machen auf alles was man tut. Ja genau. Also ich find so ne technische Library ist n gutes Beispiel die ich nach Mithilfe von TDD entwickeln kann, aber BDD vielleicht keinen Sinn macht, weil ich halt auch gar nicht weiß. Also wo ist der User Value am Ende?
Ne wenn ich jetzt zum Beispiel so Berechnungen mache hatten wir ja vorhin als Beispiel, ich kann ja auch ne ganze Library haben an Berechnungsfunktion ja die irgendwelche mathematischen Formeln abbilden oder so. Dann bin ich ganz bei dir, wie? Ja, also wie will ich das formulieren, dann am Ende ja ich würd sagen wir haben es coole Folge zusammengefasst. BDD ist irgendwie so kommunikationsgetriebenes TDD.
Wenn man so auch noch mal sich, das sag ich mal, auf der Zunge zergehen lässt und drüber nachdenkt, kann man sagen, dass wir schon mehr Richtung BDD gehen als klassisches TDD. Ich kann nicht versprechen, dass ich jetzt immer sage, ja, wir arbeiten nach BDD, ich glaub für mich ist es weiter TDD, aber Fakt ist, und das ist die Key Message kommunikationsgetrieben, also wirklich die Kommunikation und das fachliche in den Fokus stellen um einfach daraus die Benefits zu ziehen.
Und das macht absolut Sinn. Und das Ziel verfolgen wir ja auch und deswegen kann man da auch von BDD bei uns privat jetzt oder im beruflichen Kontext sprechen. Ja. Ja, ansonsten falls es Fragen dazu gibt, Liebe Zora, Liebe Zora, du weißt es vielleicht schon, ansonsten sag ich es jetzt noch mal. In den Shownotes findest du unsere Mail, da kannst du uns
drüber erreichen. Stell dir gerne die Fragen, wir antworten super super gerne, ansonsten schau auf unserem Discord vorbei, kannst auch da gibt es n Feedback Channel. Wo denn auch quasi andere Leute aus der Community ihre Meinung dazu kundtun können. Und das machen Sie auch sehr
gerne. Es ist immer n supergeiler Austausch ich freue oder ich was heißt ich wir beide freuen uns immer wenn es zu einer Folge Feedback gibt und dann quasi die Diskussion so auf den Discord weitergeführt wird, weil ganz klar, das war jetzt quasi die Sicht von Fabi und mir zu dem Thema ne und es gibt unterschiedliche Sichtweisen
dazu. Ansonsten, wenn der Podcast weiterhin gefällt oder ab jetzt gefällt, wie auch immer, findest du auch n Spendenlink in den Shownotes würden wir uns mega drüber freuen, ansonsten lass auch gerne ne Bewertung, da Teile den Podcast abonnier den Podcast. Es gibt auch so ne absolut abgefahrene Glocke die man drücken kann um immer benachrichtigt zu werden, kommt richtig cool, ansonsten sehen wir uns alle nee hören wir uns alle nächste Woche wieder, habt ne schöne Zeit bis dahin fabi
wir sehen uns sogar. Und bis dahin eure Coding Buddies gemeinsam besser. Vielleicht so nicht so Deutschland, ne die die die die die die die die die die das könnte könnte auch so ein richtig geiler Rap sein.