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.