Latest / Coding Buddies | Tech & Dev-Mindset / #142 Behavior Driven Development: Ein Schritt weiter als TDD

Transcript

#142 Behavior Driven Development: Ein Schritt weiter als TDD · Coding Buddies | Tech & Dev-Mindset

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