Luca und Falko besprechen Behaviour Driven Development (BDD), eine Technik zum Erstellen automatisiert testbarer Spezifikationen — testgetriebene Entwicklung auf Feature-Ebene.
In dieser Folge des Podcasts wird das Konzept des Behavior-Driven Development (BDD) detailliert erörtert. Die Diskussion umfasst die Grundlagen von BDD, seine Rolle in der Softwareentwicklung, die Verbindung zur DevOps-Philosophie und die Herausforderungen bei der Implementierung von BDD in Teams. Es wird betont, wie BDD zur Verbesserung der Kommunikation zwischen Entwicklern, Testern und Fachexperten beiträgt und wie es in verschiedenen Testebenen, einschließlich Unit-Tests und Systemtests, angewendet wird. Zudem werden praxisnahe Beispiele und Tipps für die effektive Anwendung von BDD sowie die Integration in vorhandene Entwicklungsumgebungen und Tools besprochen.
Inhalt
- Einführung in Behavior-Driven Development (BDD)
- Verbindung von BDD und DevOps
- Die Rolle von BDD in der Softwareentwicklung
- Herausforderungen bei der Implementierung von BDD
- Kommunikationsverbesserung durch BDD
- Anwendung von BDD in verschiedenen Testebenen
- Praktische Beispiele für den Einsatz von BDD
- Integration von BDD in Entwicklungsumgebungen und Tools
- Best Practices und Tipps für die effektive Nutzung von BDD
Shownotes
https://en.wikipedia.org/wiki/Behavior-driven_development
Gojko Adzic, „Specification by Example“, ISBN 978-1617290084
https://cucumber.io/docs/gherkin/
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner und Luca Ingianni
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts
DevOps – auf die Ohren und ins Hirn
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und mir, Falko Werner
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte
Wir freuen uns heute, das Thema Behavior-Driven Development mit euch zu besprechen
und wollen es von verschiedenen Seiten beleuchten
Dabei sollt ihr herausfinden, wie ihr Behavior-Driven Development nutzen und einsetzen könnt
und was der Zusammenhang zu DevOps ist
Zu Gast haben wir heute einen der üblichen Hosts, Luca Ingiarni
Er ist Berater
und Coach in allen Bereichen, die mit DevOps und Agilität zu tun haben
Lieber Luca, wir haben in diesem Podcast die Tradition, die du auch kennst
all unsere Gäste nach ihrer persönlichen Definition von DevOps zu fragen
Du hast das schon ein, zwei Mal gemacht
Nichtsdestotrotz, was ist deine Definition von DevOps?
Ach Gott, ich hoffe, jetzt fühlt sich keiner der Hörer bemüßigt nachzuschauen
was ich die letzten Male so erzählt habe
weil das widerspricht sich dann wahrscheinlich
weil auch meine Definition von DevOps, glaube ich
entwickelt sich im Laufe der Zeit irgendwie weiter
Also da, wo ich momentan angekommen bin, ist halt, dass es eine Weiterentwicklung der Agilität ist
dass es die Verbindung von Agilität ist mit Technologie
mit dem Ziel, noch mehr Feedback-Schleifen zu bauen
mit dem Ziel, noch größere Bereiche des Wertstroms zu überdecken
und noch mehr Leuten dabei zu helfen, gute Produkte zu bauen
Okay, vielen Dank
Dann lass uns mal ein Stück in das Thema Behavior-Driven Development einsteigen
Was ist die grundlegende Problemstellung, die man hat, wenn man sich mit dem Thema auseinandersetzen will?
Die grundlegende Problemstellung ist vielleicht die
dass man sich wünscht, automatisierte Tests zu haben auf funktionaler Ebene
Das heißt, auf der Ebene dessen, welches Verhalten man sich eigentlich wünscht von seinem Produkt
Man kennt ja automatisierte Tests, zum Beispiel von Test-Driven Development, von Unit-Tests oder sowas
die auf sehr, sehr niedriger Ebene sind
die nur einzelne Fragmente eines Produktes untersuchen
und dasselbe aber auf wirklich hoher Ebene zu tun
auf Ebene des Gesamtproduktes zu tun
oder nennenswert großer Blöcke davon
Das ist wesentlich verzwickter und wesentlich weniger üblich
Da ist man ganz häufig noch in der Gegend, wo dann auch manuelle Tests gemacht werden
Na, weil da ist man dann in Richtung Benutzerschnittstelle unterwegs
Da ist man in Richtung von wirklich, im Zweifelsfall auch sehr komplexen Gesamtsystemen unterwegs
Und BDD ist ein Weg, um eben automatisierte Tests auf funktionaler Ebene möglich zu machen
Und das heißt gleichzeitig auch, das ist nämlich ganz verrückt
Das ist ja auch eine Art, Spezifikationen zu schreiben
Also wer vielleicht das klassische V-Modell kennt
Wo man den linken Ast dieses Vs hat
Wo man von Grobspezifikationen, Feilspezifikationen sich runterarbeitet
Bis hin zum Entwickeln, zum Coden
Und dann auf dem rechten Ast wieder hochmarschiert
Zu immer großräumigeren Tests
Unit-Tests, Teilsystem-Tests, System-Tests, Funktional-Tests und so
Und BDD sitzt auf beiden Zweigen von diesem V
Das ist eine ganz lustige Besonderheit
Das ist nämlich
Die anderen Bezeichnungen für
Oder eine andere Bezeichnung für BDD ist zum Beispiel
Specification by Example
Also Spezifikationen verfassen dadurch, dass man konkrete Beispiele gibt
Klammer auf
Und dann hat man dann auch noch eine andere Bezeichnung für BDD
Und dann diese Beispiele direkt als Testfälle verwendet und die durchtestet
Klammer zu
Das heißt letztendlich
BDD ist, wenn man sich mal die Testpyramide, so MyCone im Hinterkopf anschaut
Relativ hoch angesiedelt, wie du gesagt hast
Wie viele Tests auf der Ebene führt man dann normalerweise aus?
Ich habe immer so im Hinterkopf
Je weiter unten, desto mehr
Je weiter oben, desto weniger
Ja, das ist in diesem Fall natürlich auch so
Einfach deshalb, weil
Weil diese Tests von ihrer Natur her ein bisschen aufwendiger sind
Oder sogar viel aufwendiger sind
In der Errichtung
Die brauchen teilweise auch sehr lange, um abzulaufen
Ein Unit-Test per Definition hat ja keinerlei Seiteneffekte
Das ist die Definition eines reinen Unit-Tests
Dass der nur innerhalb dieser einen Funktion irgendwie rumsaust
Und wenn du das machst, ist eine Millisekunde natürlich eine sehr lange Zeit
Wohingegen
So ein funktionaler Test, der
Greift dann vielleicht sogar auf entfernte Dienste zu
Von Dritten oder sowas
Also das kann schon mal sein
Dass der im Zweifelsfall auch ein paar Minuten braucht
Bis der endlich mal durch ist
Wenn der irgendwas richtig Kompliziertes macht
Das kann schon sein
Die Frage ist ja auch immer
Und das ist die Kunst eines guten Testmanagers
Wie komme ich an das Vertrauensniveau für mein Produkt hin, das ich brauche
Und der Extremfall, den ich mal hatte, war
Wir hatten nur einen einzigen BDD-Test
Das war also
Wenn man böse ist, kann man sagen
Das war ein Small-Test-Test
Aber allein dieser eine war so machtvoll
Einfach um für uns selber fortwährend nachzuweisen
Ganz grundlegend
Unser System lebt noch
Und wir hätten dann
Natürlich auch noch mehr andere Tests dran häkeln können
Aber das haben wir dann gar nicht so als notwendig empfunden
In dem speziellen Fall
Das haben wir auf anderen Testebenen abgefrühstückt
Und eigentlich hat dieser eine Test dazu gedient
Zu verifizieren
Ja, die anderen Testebenen, die lügen uns nicht an
Sondern die erzählen weiterhin die Wahrheit
Wenn wir, das war eine Maschine
Wenn wir der Maschine
Wenn wir die Maschine kommandieren
Zu sagen, fahr auf diese Koordinaten
Dann fährt die da auch ganz tatsächlich physisch hin
Wir haben das dann nachgewiesen
Mit einem kleinen Tasterle
Ist die Maschine dann dagegen gefahren
Und dann haben wir gesagt, wunderbar
Das Gesamtsystem
Maschine von oben bis unten
Und letzten Endes sogar unser Test-Framework
Funktioniert noch
Und das war alles, was wir brauchten an der Stelle
Okay
Wir haben jetzt gerade so ein bisschen die Problemstellung beleuchtet
Ich würde zum nächsten Thema übergehen
Und zwar BDD
Was ist es überhaupt?
So ein bisschen angerissen hast es
Wollen wir das Ganze noch ein bisschen vertiefen?
Na klar, genau
Also, ich habe ja gesagt
Es sitzt so zwischen den Stühlen
Zwischen Spezifikation und Testen
Und zwar in der Form
Dass ich da
Natürlichsprachige Spezifikationen verfasse
Typischerweise in einer bestimmten Syntax
Die so ein bisschen
Sogenannte Gherkin-Syntax
Die ist eigentlich völlig harmlos
Das ist jetzt also keine irgendwie abgefahrene Syntax
Sondern der Kennzeichner für die ist eigentlich nur
Dass die Sätze mit
Einem von drei Wörtern anfangen
Nämlich given, when oder then
Das war’s
Da gibt es noch ein paar Sonderlocken
Aber das ist jetzt mal so die Grundlage
Und das war alles
Das sind also wirklich natürlichsprachige Sätze
Und die Idee dahinter ist, dass auch ein
Nicht-Tester
Ein Nicht-Software-Entwickler
Ein Fachexperte in der Lage ist
Das zu lesen und zu verstehen und zu sagen
Ja, dieses Verhalten des Systems
Das hier beschrieben ist
Das ist das, was ich mir wünsche
So, das ist das eine
Und das andere ist
Jetzt möchte ich die ja automatisiert ausführbar machen
Das muss ich also irgendwie die Brücke schlagen
Von diesen natürlichsprachigen Spezifikationen
Hin zu einer automatisierten Testausführung
Und um gleich alle vorweg zu beruhigen
Also da kommt jetzt keine KI
Die versucht englische Sätze in Testcode umzuwandeln
Sondern an der Stelle muss dann schon ein
Testcode umgewandelt werden
Menschlicher Tester eben tatsächlich
Testcode verfassen
Und was ein BDD
Engine
Dann macht, ist, dass sie
Ein Mapping durchführt
Wenn ich diesen natürlichsprachigen Satz lese
Dann verstehe ich daraus
Aha, ich muss folgende
Ruby-Funktion, Python-Funktion
Wie auch immer du deine Tests konkret implementierst
Ausführen
Und dann
Und auf diese Weise bekomme ich dann meine automatisierten Tests
Mhm
Also letztendlich das, was auch ein
Tester, der das händisch machen würde
Eine Art von Skript hat
Auch tun würde
Das stimmt, genau
Und was ist dann der Unterschied zu
Akzeptanztests?
Der Unterschied ist eigentlich
Nur einer in der
Im Testgegenstand
Grundsätzlich
Macht BDD halt
Automatisiert
Automatisierte Tests
Auf funktionaler Ebene
Das können auch Akzeptanztests sein
Ein funktionaler Test heißt ja einfach nur
Ich mach was, was
Die Funktion
Das Verhalten
Meines eigentlichen Produkts beobachtet
Und das kann ja durchaus auch ein Akzeptanztest sein
Dass ich sage, also
Damit ich dieses Produkt als irgendwie
Gelungen akzeptiere
Muss es folgende
Verhalten vorweisen
Und das kann ich ja als BDD-Test formulieren
Also
In dem Sinne Akzeptanztest ist halt ein Sonderfall
Eine besondere Sichtweise, wenn man so will
Auf funktionale Tests
Das ist alles
Man kann das mit BDD
Ansätzen automatisiert machen
Und häufig kenne ich Akzeptanztests
Zumindest in vielen Umfeldern
Dass sie durch zum Beispiel User
Als User Acceptance Test
Zum Beispiel umgesetzt werden
Und häufig noch manuell stattfinden
Genau
Und du kannst ja da
Das Ding einfach umdrehen
Und kannst sagen
Ich setze mich nicht erst mit meinen Fachexperten zusammen
Wenn das Produkt fertig gemacht ist
Sondern ich setze mich mit ihm im Vorfeld hin
Und dann soll er mir mal einfach erzählen
Was erwartet er denn
Was will er denn sehen von diesem System
Dass er sagt, so passt mir das
Und dann schreiben wir das
In dieser Gökken-Syntax hin
Und dann haben wir einen fertigen Testfall
Den können wir zu jedem Zeitpunkt
Neben dieses System halten
Und sagen, gefällt uns was wir sehen
Sind die Tests schon grün
Das heißt wir können Akzeptanztests
Auch dann machen
Wenn wir kurz vorm Release stehen
Und der Fachexperte vielleicht im Urlaub
Oder im Wochenende
Oder an anderer Stelle ist
Und machen uns damit ein Stück unabhängiger
Ja, das ist richtig
Du gewinnst halt ganz grundsätzlich
All die Vorteile, die du aus automatisierten Tests hast
Genauso wie du sagst
Man gewinnt diese Unabhängigkeit
Man gewinnt sicherlich Geschwindigkeit
Man gewinnt auch die Wiederholbarkeit
Ich muss den jetzt nicht ständig irgendwie neu piesacken
Und sagen, hier probier nochmal, probier nochmal
Geht’s jetzt und so
Sondern zu jedem Zeitpunkt während der Entwicklung
Kann ich einfach meine BDD-Test-Suite laufen lassen
Und kann mich selber vergewissern
Geht noch alles
Oder habe ich jetzt versehentlich irgendwo anders was kaputt gemacht
Zum Beispiel
Aber ich habe auch in der Umkehrung
Den schönen Vorteil, ich weiß genau wann ich fertig bin
Weil hier habe ich eine Liste von Akzeptanztests
Die sind schon
Im Vorab
Diskutiert, abgestimmt
Und dann kann ich einfach sagen, sobald die alle grün werden
Bin ich fertig
Mit dieser Funktion
Das ist also
Ein
Form des Shift-Lefts
Dinge frühzeitig zu tun, die man
Sonst im, ich sag jetzt mal
Klassischeren Vorgehensweisen
V-Modell, Wasserfall oder Co
Erst später, vielleicht sogar manuell
Gemacht hätte, wiederholbar
Automatisiert und von dem
Letztendlich auch frühzeitig
Mit dem Thema zu befassen
Genau so ist es
Und auch ansonsten kriegst du ja all die schönen Vorteile
Die du aus Automatisierung kriegst
Zum Beispiel diese Verschriftlichung
Das ist jetzt nicht mehr Geheimwissen
Irgendeiner Person
Irgendeines Fachexperten, irgendeines Testers oder so
Sondern das ist jetzt hier schwarz auf weiß
Das sind die Erwartungen
Die wir an das System haben
Das ist das Verhalten, das wir
Erwarten, das wir voraussetzen
Das steht da
Das kann sich jeder anschauen, den das interessiert
Darüber kann man diskutieren
Dann hat man ein gemeinsames Verständnis
Man hat auch nicht zum Beispiel das Risiko, dass der eine Tester
Es ein bisschen mehr so macht und der andere ein bisschen mehr so
Und dann je nachdem, ob es der Heinz oder der Mike
Gemacht hat, wird der Test dann halt grün oder nicht
Sondern man kriegt diese schöne
Klarheit
Und wie gesagt
Das Tolle ist halt
Ich kann meine Abnahmetests
Im Voraus festlegen
Und zu jeder Zeit laufen lassen
Ich kann also sogar
Testgetriebene Entwicklungen machen
Auf der Feature-Ebene, auf der funktionalen Ebene
Sozusagen das klassische Red-Green-Refactor
Das geht dann halt nicht mehr auf Unit-Test-Ebene nur noch
Sondern wenn so ein BDD-Test
Einmal verfasst ist, als natürlich
Spezifikation, dann wenn ich den laufen lasse
Dann erwarte ich, dass der erstmal rot ist
Und dann tüftel ich weiter
So lange bis alles grün ist
Und dann kann ich in aller Ruhe refactoren
Und kann mir sicher sein, dass ich beim Refactoren
Mir nicht ein Ei lege, weil ich kann jederzeit
Nachtesten, gehen noch alle Funktionalitäten
Die mein Fachexperte sich von mir gewünscht hat
Das ist also eine Paralelität
Zu Test-Driven-Development auf Unit-Test-Ebene
Gibt es denn Unterschiede
Die man dabei beachten muss
Zwischen BDD und TDD
Naja, es sind
Verschiedene Sachen. BDD ist ja einfach nur
Automatisiertes Testen auf funktionaler
Ebene und
TDD, ich weiß was du meinst
Man impliziert
Immer ganz gerne, dass das halt auf Unit-Ebene stattfindet
Aber grundsätzlich heißt TDD ja nur
Ich schreibe erst meine Tests und dann
Die Funktionalität, die diese
Testfälle überhaupt erfüllt
Auf welcher Ebene ich das mache
Ist jetzt erstmal dahingestellt
Sind also alles
Treiber für
Driven-Development-DDs
Gibt natürlich auch andere DDs
Einfach zum Abgrenzen
Model-Driven-Development oder ADD
Gibt es etwas, was wir an der Stelle
Mit besprechen sollten
Ja, ich weiß nicht
Also
Model-Driven-Development ist ja dann nochmal wieder
Ein bisschen was anderes, wo man sich also erstmal
Ein Muster
Sozusagen seines
Funktionalen Elementes, ein Prototypen
Wenn man so will
Ein Mock, wie auch immer, baut
Und den kann man natürlich auch
Verwenden
Um, ich sag mal
Als ausführbare Spezifikation
Wenn man so will
Aber der Unterschied ist halt der
Model-Driven-Development und solche Sachen
Die setzen immer noch sehr viel technisches
Know-How voraus. Ich finde das Schöne an
An BDD
So wie es üblicherweise
Eingesetzt wird mit der Gherkin-Syntax
Und so weiter
Dass das auch für einen
Nicht
Software-Entwickler
Zugänglich ist
Ich meine, natürlich wird der am Anfang so ein bisschen fremdeln
Mit dieser Syntax und so
Und man soll um Himmels Willen
Nicht auf die Idee kommen
Einen Fachexperten solche BDD-Testfälle
Selber schreiben zu lassen, es sei denn
Der weiß, wie man Testfälle schreibt
Aber
Aber ganz grundsätzlich ist das einfach viel
Viel zugänglicher
Okay
Ich kenne noch die Abkürzung
ATDD
Akzeptanz
Test-Driven-Development
Ist das was anderes als BDD?
Ja, es hat halt eine andere Sichtweise
Also du kannst
ATDD auch
Mithilfe eines BDD-Frameworks machen
Verstehst du? Du kannst ja Akzeptanz-Tests
Verfassen
Mit deinem BDD-Framework
Deiner Wahl
Und dann auf diese Weise
Testgetrieben entwickeln, kannst du machen
Gibt es für dich noch andere Dinge
Die man abgrenzen sollte
Zu Behavior-Driven-Development
Oder über die wir jetzt an dem Punkt gut reden sollten
Ich finde, es gibt noch eine Sache
Die haben wir in unsere
In unsere Notizen reingeschrieben
Als wir uns über die Episode unterhalten haben
Nämlich, was ist denn jetzt der Unterschied
Zum Beispiel zwischen BDD und AB-Tests
Und der Unterschied ist ganz einfach der
Dass BDD, ich sag jetzt mal
Von seinem Ansatz her
Stattfindet vor
Der Auslieferung an den Kunden
Und das ist ja auch so
Vor einem Release
Das kann ich jederzeit machen
Während der Entwicklung, genauso wie ein Unit-Test oder sowas
Nichts hindert mich
Das sollte man vielleicht auch sagen
Nichts hindert mich natürlich daran
Diese Tests auch nachträglich
Nach der Auslieferung immer wieder laufen zu lassen
Und als Health-Checks im Prinzip einzusetzen
Für mein System und zu sagen
Kann ich jetzt zum Beispiel immer noch
Was weiß denn ich, wenn ich einen Online-Shop habe
Kann ich denn immer noch was bestellen?
Geht das denn?
Diesen Testfall, den habe ich zwar am grünen Tisch entwickelt
Und in meiner irgendwie
Testumgebung ausgeführt
Aber warum sollte ich den nicht auch in der Live-Umgebung ausführen können?
Kann man also machen
Ist das sowas wie eine
Synthetische Transaktion, wie
Einem unserer früheren Podcasts zum Thema
Observability diskutiert?
Ja, genau
Das wäre eine synthetische Transaktion
Genau, das stimmt
Okay, dann habe ich das soweit verstanden
Wir waren gerade bei BDD und AB-Tests
Du hast gerade erklärt, was die Vorteile von
BDD sind, wie man das letztendlich nutzen kann
Das ist vorrangig
Das ist vorrangig
Dafür ausgelegt ist es, während der Entwicklungsphase zu nutzen
Man kann es genauso auch umsetzen
In der Live-Umgebung
Dann sind wir bei
Observability, synthetischen Transaktionen
Aber wie sieht das jetzt mit AB-Tests aus?
Die sind letztendlich
Dafür nicht gedacht, sondern
Genau, die verfolgen ja ein ganz anderes Ziel
BDD ist ja ein Test
Auf der funktionalen Ebene
Tut das Ding das, was ich
Von ihm erwarte, was ich formuliert habe
Irgendwie
Während AB-Tests
Sind ja Tests, die nach der Auslieferung stattfinden
Indem man
Verschiedenen Benutzergruppen
Verschiedene Varianten des Systems
Zur Verfügung stellt
Und dann versucht, aus dem Benutzerverhalten zu schließen
Welche sich besser eignet
Mit anderen Worten
Das ist kein Test in dem Sinne
Sondern das ist ein Experiment
Und das ist ein Experiment nicht auf funktionaler Ebene
Sondern auf Wertebene
Welche der gegebenen Funktionalitäten
Der gegebenen Verhaltensweisen, die ich da darstelle
Empfinden die Anwender
Als wertvoller
Das ist eine Frage, die die BDD gar nicht
Zu beantworten versucht
Funktioniert ja auch nur im Zusammenhang
Mit den Nutzern
Die das System wirklich verwenden
Und BDDs
Werden letztendlich
Dafür eingesetzt, die Entwicklungsprozesse
Oder die Stabilität des Systems
Als teilweise noch Regressionstest
Zu verwenden
Wenn man jetzt überlegt, man möchte BDDs
Also Behavior-Driven entwickeln
Behavior-Driven-Development-Tests einsetzen
Gibt es bestimmte Techniken
An die man denken sollte?
Naja
Wie macht man sowas denn überhaupt?
Der erste Schritt ist, dass man
Diese natürlichsprachige Spezifikation
Mal verfasst
Das bedeutet, man wird sich in der Regel
Zusammensetzen mit
Einem Fachexperten
Und
Gibt es ja diesen berühmten
Begriff von den Three Amigos
Ich weiß gar nicht, wer sind denn die ganzen Amigos?
Also der Kunde ist einer
Und ich glaube klassischerweise ist der Entwickler der Nächste
Und der Product Owner der Dritte, war das so?
Also ich kenne viele
Es gibt ja auch den Film und Chevy Chase und Co
Aber im agilen Umfeld
Im agilen Umfeld hätte ich jetzt gesagt
Business
Also entweder Product Owner, Kunde oder Kundenvertreter
In irgendeiner Form, Fachexperte
Der Zweite ist für mich immer
Die Entwicklung, also die, die das umsetzen
Und die Dritten die Tester
Die an der Stelle
Überlegen, wie kriegen wir
Sichergestellt, dass das, was der
Entwickler entwickelt, mit dem übereinstimmt
Was der Anforderer
Sich ausgedacht hat
Genau
Und insofern
Ihr merkt auch, liebe
Zuhörer, mir ist das gar nicht so wichtig, wer die Amigos
Im einzelnen sind, das Wesentliche ist halt
Dass man die Leute an den Tisch bringt, die
Dazu beitragen, dass
Das gute
Spezifikationen werden
Schrägstrich gute Tests werden
Dass da am Ende ein rundes Produkt dabei rauskommt
Und da werden bestimmt ein ganzer Haufen Amigos
Irgendwie auflaufen, im Zweifelsfalle
Ja, je weiter
Das Team cross-funktional ist
Desto mehr verschiedene Rollen
Spielen damit rein
Das ist ein Stück der Gedanke von
Development und Operations zusammenzubringen
Bereiche, die im klassischen Umfeld
Ja, mehr oder weniger nichts
Miteinander zu tun hatten, außer die
Wall of Confusion, über die sie bestimmte
Effekte drüber geworfen haben
Pakete, die gebaut worden sind
Auf einem Entwicklerrechner, der dann
In der Form produktiv
Gehen soll und wo sich dann
Operations drum kümmern sollte, dass das funktioniert
Je mehr man letztendlich
Den Wertstrom betrachtet
Also von Anfang, von der Anforderung, von dem
Kunden gedacht, bis hin zur Funktionalität
Die dem Kunden wieder zur
Verfügung gestellt wird, umso
Mehr Beteiligte kann man in dem
Prozess haben, ja
Ansonsten, gut, Techniken sind
Gespräche, gibt es noch andere Dinge, auf die man
Auf der Ebene achten sollte oder
Wenn nicht, würde ich sagen, gehen wir zum nächsten
Thema über, welche Unterstützung
Durch Tools kann man an der Stelle bekommen
Genau, also ganz grundsätzlich
BDD ist etwas, was man
Mit Tool-Unterstützung macht
So wie Unit-Test, da hast du immer
Ein Unit-Test-Framework und bei BDD hast du auch immer
Irgendein BDD-Framework
Das eben für dich die automatisierte
Testausführung übernimmt
Und in dem speziellen
Fall halt auch das Mapping von
Spezifikation auf
Test-Code, wie auch immer der
Lied ausgedrückt ist
Da gibt es also BDD-Frameworks
Gibt es für jede mir bekannte
Programmiersprache
Ich glaube in JavaScript gibt es Jasmine
Unter anderem
Es gibt natürlich den Uropa
Von in allen, Cucumber für
Ruby
Die sind auch diejenigen, die mit der Gherkin-Syntax
Angefangen haben
Es gibt Behave unter Python
Und so weiter und so weiter, also für jede
Programmiersprache eurer Wahl
Gibt es
Ein entsprechendes Framework
Und vielleicht sollte man das an der Stelle auch erwähnen
Wir sind ja so weit weg vom eigentlichen
Produktionscode, dass
Bloß weil jetzt dein Produkt in, weiß nicht, Java
Geschrieben ist, heißt das nicht, dass
Auch dein BDD-Framework
Ein Java-Framework sein muss, sondern du kannst
Deine Tests
Auf der funktionalen Ebene
Ja auch von mir aus in
Ruby formulieren
Du brauchst halt nur die passende
Laufzeitumgebung, damit du sie
Umsetzen kannst
Wie gut sind solche
Frameworks und Vorgehensweisen
In Continuous Delivery
Oder Continuous Integration Tools
Integriert oder integrierbar
Sehr gut
Also das läuft wirklich ganz geschmeidig
Das kannst du so wie jedes andere
Test-Framework da einfach
Anflanschen
Und die, das hängt natürlich
Von den Spezifika der jeweiligen Frameworks ab
Aber alle, die mir bekannt sind, die sind auch
In der Lage, zum Beispiel
Diese klassischen
Ex-Unit-Resultat-Dateien
Zu generieren, die dann auch wiederum
Von allen gängigen
CI-Tools konsumiert werden können
Also das stellt normalerweise eigentlich
Keine wirkliche Schwierigkeit dar
Das passt schon
Die Pferdefüße, wenn man BDD
Verwendet, die liegen ganz woanders
Okay, da kommen wir bestimmt noch drauf zu sprechen
Erstmal würde ich
Ein Gefühl dafür kriegen, wie das im konkreten
Beispiel aussieht, mit so einem
BDD-Testfall
Kannst du uns sagen, was
Letztendlich da
Das Pudels Kern ist
Genau, also das ist natürlich ein bisschen undankbar
In einem Podcast
Ich werde es trotzdem versuchen und
Liebe Hörer, ihr müsst euch auch vorstellen, dass ich ganz wild
Mit meinen Händen rudere, indem ich versuche, das noch ein bisschen
Plastischer zu machen, hilft aber auch niemandem
Also, nehmen wir uns mal
Als Beispiel, wir entwickeln
Irgendwie hier einen Online-Shop
Kennt natürlich jeder von euch
Das ist also eine Anwendung, die natürlich auch
Sehr dankbar sich mit BDD
Testen lässt, weil da ist
Ziemlich klar, wie man an die Schnittstellen
Rankommt, wie man sowas
Automatisieren kann
Und da würde ich hergehen und würde ich eine
Spezifikation verfassen
Okay, sagen wir mal
Es geht jetzt erstmal darum, sich einzuloggen oder sowas
Dann könnte ich ja
Die Spezifikation verfassen, ich sage
Given
I am at
The login page
Ich stelle einen Grundzustand ein
When
I enter
The correct password
Then
I am transferred to the welcome page
Oder sowas
Das wäre ein ganz klassischer Ablauf
Und ihr merkt schon, liebe Hörer
Da habe ich natürlich ein bisschen was rausgelassen
Man braucht bestimmt außer dem Passwort auch noch einen Benutzernamen oder so
Aber im Sinne der Einfachheit
Given
Irgendeinen gegebenen Grundzustand
When
Ich stimuliere das System irgendwie
Then erwarte ich
Ein bestimmtes
Eine bestimmte Reaktion des Systems
Ganz klassisch, ganz banal
So, das habe ich jetzt natürlich
Sprachlich so formuliert
Und dann werde ich in
Sagen wir mal
In Cucumber
Werde ich dann eine entsprechende
Ruby-Funktion haben
Die hat dann ein
Ein Markup
Mit dem das BDD-Framework erkennen kann
Okay, wenn der Benutzer schreibt
Given I am at the login page
Dann heißt das für mich
Ich muss meinen Mock-Browser
Zu
Dieser Login-URL
Schicken
When I enter
A password
Dann weiß er
Dann muss er das mappen auf eine Ruby-Funktion
Und dieses Mapping, das geschieht auch
Ganz stumpf in der Regel einfach über reguläre Ausdrücke
Da steht dann einfach
So ein Stück von diesem Satz nochmal
Und das sucht dieses BDD-Framework
Das sagt dann
Wenn ich den folgenden Text
In der Spezifikation lese
Auf welche
Konkrete Funktion
In einer Programmiersprache
Muss ich die anwenden
Welche muss ich jetzt ausführen
Welche muss ich laufen lassen
Das übernehmen die Frameworks
Dann dieses Mapping
Das heißt, man muss zwar den Text
Quasi kopieren
Aus dem Behavior-Driven-Test-Fall
Aus der Beschreibung, aus der Spezifikation
Das dann in ein Stück
Quellcode übernehmen
Und daraus quasi von
Beschreibungstext in
Ausführbaren Code
Das Mapping übernimmt dann das Framework
Genau, und viele Frameworks
Helfen einem dann auch dabei, wenn die zum Beispiel
Ein neues Stück Text sehen
Für das sie nichts gemapptes finden können
Dann spucken sie direkt einen Funktionsrumpf aus
Und sagen, magst du nicht den direkt nehmen
Und den muss man dann natürlich
Noch selber mit Leben füllen
Das ist klar, das kann dann wiederum das Framework nicht übernehmen
Dass es dann sagt, wie weiß ich denn zum Beispiel
Meinen Automatenformat
Im automatisierten Browser an
Zu dieser URL zu gehen oder sowas
Das kann es nicht
Machen das dann üblicherweise die Entwickler mit
Die dann das mitentwickeln
Oder ist das eine Aufgabe bei Testern
Oder kommt so der klassische
Kommt drauf an, mal so, mal so
Ja, es kommt natürlich drauf an
Aber ich sag jetzt mal, in der Regel
Machen das dann tatsächlich Tester
Machen das Leute, die einfach geübt im Umgang
Mit solchen Automatisierungswerkzeugen zum Beispiel sind
Ist das so ein
Ein Tester mit Automatisierungshintergrund dann
Also nicht unbedingt ein manueller Tester
Sondern jemand, der sowas, wie du gesagt hast
Schon das ein oder andere Mal gemacht
Gesehen hat und weiß, worauf er achten muss
Okay
Genau
Und natürlich, wenn ein Entwickler auf Draht ist
Dann kann der das auch selber machen
Aber in der Regel, sagen wir mal
Kristallisiert sich es halt irgendwie raus
Es gibt Leute, die sind gut da drin
Diese Automatisierungen zu verfassen
Und die machen das dann
Okay
So
, aber jetzt ist das natürlich noch nicht so
Nicht so richtig wahnsinnig testgetrieben
Weil jetzt muss ich ja trotzdem immer noch
Eine Spezifikation verfassen
Und dann muss jemand einen Test verfassen
Das kann er zwar auch gleich machen
Aber jetzt kommen wir zu etwas, was
Sich in der Praxis häufig als sehr charmant herausstellt
Nämlich
Die Anzahl der verschiedenen
Aktionen, die man tatsächlich ausführt
Gegen eine Software
Die sind relativ gering
Zum Beispiel, geh zu einer URL oder so
Du hast vielleicht 100 verschiedene URLs
In deinem Produkt
Aber
Ganz grundsätzlich
Zu einer URL gehen
Ist ja immer dieselbe Funktion
Der Witz ist nämlich
Du kannst
Die natürlichsprachige Spezifikation
Auch parametrieren
Da gibt es dann auch
Je nachdem, welches Framework
Gibt es da verschiedene Auszeichnungen
Beliebt sind geschweifte Klammern zum Beispiel
Und dann weiß dieses Framework auch
Es gibt zum Beispiel eine generische Funktion
Geh zu einer URL
Und dann
In der natürlichsprachigen Spezifikation
Steht dann in den geschweiften Klammern drin
Was denn in dem Fall die konkrete URL ist
Also ich
http
Doppelpunkt
Doppel Slash
Logo
Host Slash
Login
Was auch immer
Ne?
Und dann
Kommst du an den Punkt
Dass
Überhaupt nicht mehr
Für jeden einzelnen Testfall
Für jede einzelne Spezifikation
Ein Tester tatsächlich Code schreiben muss
Sondern dann kommst du ziemlich schnell
Auf den Grundstock von
Ich sag jetzt mal
20, 30, 40 Funktionen
Die du für
Ich weiß nicht
Tausende von Testfällen einsetzen kannst
Gibt es dafür
Bibliotheken
Die man nutzen kann
Die vielleicht
Quasi
Wiederverwendbar sind
Begrenzt
Begrenzt
Also sie sind dann schon
Eher produktspezifisch
Das heißt
Da muss man
Dann wirklich
Selbst sammeln
Und entwickeln
Okay
Genau
Aber das Schöne ist eben
So viel muss man am Ende
Gar nicht sammeln
Das könnt ihr euch selber überlegen
Auch bei meinem Beispiel
Vorher mit
Passwort eingeben
Das ist ja einfach nur
Irgendein String
In irgendein Textfeld
Und wenn du deine
Test
Deinen Testcode
Entsprechend generisch
Formulierst
Dann ist das
Dann
Funktioniert das für
Benutzernamen
Genauso wie für
Passwörter
Genauso wie für
Keine Ahnung
ISBNs
Etc.
Etc.
Etc.
Dann musst du also
Wirklich nur noch
Den natürlichsprachigen
Teil
Verfassen
Und die Automatisierung
Ist ohnehin schon
Steht ohnehin schon
Zur Verfügung
Weil du es schon
Hast halt schon mal gemacht
Okay
Das ist auch der Weg
Wie man damit anfängt
Also
Letztendlich
Erfahrungen sammeln
Ersten BDD-Testfall
Mal schreiben
Gucken wie es
Funktioniert
Und dann weitergehen
Oder gibt es
Noch weitere
Tipps
Genau
Also um zu starten
Ist es genauso
Wie du sagst
Da würde ich mir
Erstmal irgendein
Ich sag jetzt mal
Leicht zugängliches
Stück Funktionalität
Nehmen
Und da einfach mal
So ein bisschen
Das ausprobieren
Und da hat man
Relativ schnell
Glaube ich auch
Recht gute Erfolge
Gerade mit dem
Was ich gerade
Beschrieben habe
So eine Login-Funktion
Oder sowas
Die
Ich sag jetzt mal
Wenn du es noch nie
Gemacht hast
Wahrscheinlich hast du
Innerhalb von
Einer voller Stunde
Einen
Nennen wir es mal
Hello-World-Test
Das ist also
Sehr verlockend
Ich finde aber
Leider
BDD ist so ein bisschen
Heikel
Weil es gehört
Zu den Techniken
Für die man
Schon so ein bisschen
Erfahrung braucht
Bisschen Fingerspitzengefühl
Braucht
Weil es relativ
Leicht ist
In die falsche
Richtung zu laufen
Und das sehr lange
Nicht zu merken
Okay
Woran kann man das erkennen
Oder was
Typische Fehler
Die man vermeiden kann
Oder Risiken
Die man beachten sollte
Also es gibt
Eine Reihe von Risiken
Ein Risiko
Dem man sich
Vielleicht einfach
Durch
Durch Disziplin
Ein bisschen
Entledigen kann
Ist
Dadurch
Dass du dieses Mapping hast
Von natürlich sprachig
Auf irgendwie
Eine Funktion
Ist es
Relativ leicht möglich
Dass man nicht so richtig
Realisiert
Dass es eine Funktion
Schon gibt
Und dann hast du
Vielleicht irgendwie
Drei, vier, fünf, sechs
Funktionen
Die alle dieselbe
Funktionalität
Eigentlich
Implementieren
Sagen wir mal
Zu einer URL gehen
Oder sowas
Weil
, ne
Da hilft es
Also wenn man sich
Wirklich so
So eine sehr klare
Sprechweise überlegt
Und ein sehr klares
Vokabular überlegt
Um solche Dubletten
Zu vermeiden
Die ja dann auch
Irgendwann mal
Zu Schwierigkeiten
Führen können
Also manche Tests
Funktionieren
Und manche funktionieren
Nicht
Je nachdem
Welche der Methoden
Sie aufrufen
Oder sowas
Das ist also das eine
Das andere ist
Wie
Formuliere ich
Eigentlich meine
Spezifikation
Vielleicht hat
Der eine oder andere
Von euch
Liebe Hörer
Schon gerochen
Ich könnte ja jetzt
Dieses
Dieses
Given
I am
At
You know
At the login page
Oder sowas
Das kann ich entweder
So formulieren
Sehr
Ich sag mal
Spezifisch
Und natürlich
Sprachig
Oder ich kann es
Formulieren als
Given I am
At the URL
So und so
Dann wäre es viel
Leichter zu parametrieren
Aber ist nicht mehr
Produktspezifisch
Sondern ist dann halt
Irgendwie so ein bisschen
So beliebig
Liest sich nicht mehr
So schön
Gerade für
Fachfremde Leute
Die vielleicht
Nicht so richtig
Geübt darin sind
URLs zu lesen
Da kann man also
Sich auch viel
Kaputt machen
Da kann man sehr viel
Wiederverwendbarkeit
Überraschenderweise
Auch wieder einbüßen
Sogar mit dem
Versuch Dinge
Generischer zu machen
Da gibt es aber
Kein Patentrezept dafür
Sondern da muss man
Genauso die richtige
Formulierungsebene
Finden
Wo man sagt
Das ist
Natürlich
Sprachig
Menschen
Zugänglich
Aber andererseits
Halt auch noch
Griffig umzusetzen
Für einen
Für einen gewieften
Testautomatisierer
Der sagt
Ah das kann ich hier
Parametrieren
Da kann ich
Das kann ich
Kann ich verallgemeinern
Da gibt es ganz viele
Möglichkeiten
Sich in den Nesseln
Zu setzen leider
Okay
Wie sieht es denn
Mit
Kontexten aus
Bei dem
Entwicklungsteams
Betriebsteams
Oder von mir aus
Auch kombinierte Teams
Im DevOps
Zusammenarbeiten
Oder vielleicht auch
In größeren Kontexten
Wenn man jetzt
Ein Produkt hat
Mit vielen Komponenten
In einem Umfeld
Keine Ahnung
Von mehreren
Hundert
Teammitgliedern
Dass man
Dass man
Einen
BDD-Test hatte
Wirklich
Auf einer
Team-von-Teams-Ebene
Das Verhalten
Eines wirklich
Großen Stücks
Systemtesten
Oder des Gesamtsystems
Meinst du
Ist
Oder
Kann mitunter
Schwierig sein
Muss aber nicht
Wenn ich jetzt
Wirklich sehr weit
An der Oberfläche bin
Um bei unseren
Berühmten
Beispiel zu bleiben
Von dem Login-Fenster
Jetzt von diesem
Online-Shop
Was weiß denn ich
Wie viele Services
Da im Hintergrund
Daran beteiligt sind
An der Oberfläche
Sag ich jetzt erstmal
Ich kipp da halt
Irgendwie ein Passwort rein
Und drück auf
Okay
Und dann erwarte ich
Direktion des Systems
Und es kann ja sein
Dass da hinten
Eine riesen Maschinerie
Dran hängt
Aber das seh ich
Auf der Ebene
Vielleicht gar nicht
Kann aber natürlich
Auch anders sein
Insbesondere wenn es
Wenn man versucht
Teilsysteme zu testen
Und insbesondere
Wenn man versucht
Oder wenn man
Wenn man
Gezwungen ist
Komplexe Setups zu machen
Wenn ich jetzt
Ganz ganz viele
Givens hab
Um überhaupt
Meine verschiedenen
Teilsysteme
Erstmal
An die richtige
Stelle zu bewegen
Na wenn ich
Mitten im Bestellprozess
Bist
Genau
Und dann geht’s darum
Mach ich’s mit der Kreditkarte
Oder mach ich’s auf Rechnung
Oder sowas
Dann muss ich halt schon mal
So einen riesen
Kleider der Dutch
Vorne weg machen
Bis ich überhaupt mal
An dem Punkt
Angekommen bin
Um den es mir
Eigentlich geht
Da kann’s
Kann
Kann
.
Ganz mühselig sein
Sag ich mal
Aber ich glaube
Gerade in solchen
Komplexen Kontexten
Zeigt sich dann auch
Wirklich der große Wert
Weil jeder
Einzelne in dieser Kette
Kann einfach zu jedem
Zeitpunkt diesen Test
Diesen Test aus dem Regal
Nehmen und sagen
Funktioniert’s noch
Wenn ich jetzt
Mein Teilsystem
In der folgenden Weise
Abändere
Geht das Gesamtsystem noch
Das wird wahnsinnig
Machtvoll
Weil du dir noch
So eine
So eine Sicherungsebene
Einziehst
Auf dieser
Hohen Ebene
Auf der funktionalen Ebene
Auf der Systeme
Ebene
Auf der Teams-von-Teams-Ebene
Okay
Kann ich mir gut vorstellen
Dann ist so ein bisschen
Die Frage
Wie hängt das Ganze zusammen
Mit dem Zuschnitt
Von Anforderungen
Also
User-Stories auf Team-Ebene
Vielleicht auch
Features
Capabilities
Epics
Auf übergeordneten Ebenen
Ja also
Grundsätzlich
Kann ich’s auf all diesen
Ebenen einsetzen
Auch parallel
Es hindert dich ja
Überhaupt niemand daran
BDD-Style
Tests zu schreiben
Auf der User-Story
Ebene
Und das
Innerhalb des Teams
Einzusetzen
Für den Nachweis
Dass meine Teilkomponente
Macht was sie soll
Und das zugleich zu machen
Vielleicht auf der Epic-Ebene
Oder sowas
Und zu sagen
Naja
Ein ganz großer
Abschnitt meines Systems
Kann ich hier
Durch automatisierte
Akzeptanz-Tests
Zum Beispiel
Einfangen
Und ausdrücken
Kann ich machen
Okay
Sind das dann
Letztendlich
Das was man sonst
Als Erfolgs- oder
Akzeptanz-Tests
Oder Akzeptanz-Kriterien
Zu jedem dieser Elemente
In einem Backlog
Mit
Aufschreiben würde
Einfach in einer anderen Syntax
Damit es dann
Realisierbar ist
Ja und nein
In einem gewissen Sinne schon
Aber in einem gewissen Sinne
Andere
In einem gewissen anderen Sinne
Nicht
Insofern als
Sich das einstellt
Was man auch von Unit-Tests
Vielleicht kennt
Dass
Für ein gegebenes Stück System
Man eine Mehrzahl von Tests braucht
Vielleicht
Wenn du einen
Natürlichsprachigen Akzeptanz-Test
Ein
Natürlichsprachigen
Ein manuellen hättest
Dann würdest du sagen
Keine Ahnung
Das System soll nur
Gültige Logins zulassen
Oder sowas
Kannst du stumpf hinschreiben
Und der Tester füllt das dann mit Leben
Und sagt
Aha okay
Da muss ich
Falsches Passwort
Falscher Username
Leeres Passwort
Was auch immer
Der sich da so für Testfälle ausdenkt
Während so
Wenn ich das mit BDD mache
Dann
An irgendeinem Punkt
Muss ich das dann halt auch wirklich
Aufdröseln
Und sagen
Diese verschiedenen Varianten gibt’s
Und das sind die verschiedenen Reaktionen
Des Systems
Die ich erwarte
Also hinter
Gültiges Login
Dann halt
Die ganzen
Testfälle
Abbilden
Irgendwie über
Keine Ahnung
Was ist denn das
Tabellenübersichten
Oder
Wie
Baut man sowas dann auf
Tolle Frage
Genau
Weil
Vielleicht hat auch
Die ein oder andere Hörerin
Schon mit den Ohren
Mit den Augen gerollt
Wenn man sich jetzt vorstellt
Man müsste für jeden Testfall
Wieder so ein
Gesatzel sich schreiben
Given
So und so
When
Das und das
Das und das
Then
Bla bla bla
Da wirst du irre
Wenn ich mir jetzt
Login ist ja ein typischer Fall
Da kann ich mir ja locker
Weiß nicht
20 verschiedene Testfälle ausdenken
Von Benutzernamen
Passwortkombinationen
Und den entsprechenden Reaktionen
Für den Fall
Bieten die meisten Frameworks
Auch Vereinfachungen
Zum Beispiel
So wie du es gerade gesagt hast
Tabellen
Einfach wirklich ASCII Tabellen
Und dann kommt natürlich
Die Stärke von parametrierten
Testfunktionen
Zum Tragen
Dann kannst du sagen
Okay ich habe hier
Keine Ahnung
Die Spalte Username
Und da steht dann drin
Einmal der richtige
Und fünfmal der falsche
Und dann habe ich die Spalte
Passwort
Und da steht dann auch
Einmal das richtige
Und fünfmal das falsche
Und so
Und dann habe ich von mir aus
Eine Spalte Resultat
Und da steht dann
Einmal
Kommt rein
Und fünfmal
Wird zurückgewiesen
Oder so
Und auf diese Weise
Kann ich das dann schon
Sehr schön kurz und knackig
Formulieren
Und auch lesbar machen
Und erträglich machen
Sage ich mal
Insbesondere
Wiederum
Für Fachexperten
Die da vielleicht
Keinen Bock drauf haben
Sich durch
50 Seiten
Given when thens
Durchzukämpfen
Das klingt auf jeden Fall gut
Macht es einfacher
Gibt es weitere
Best Practices
Die hilfreich sind
Im Umgang mit
BDD
Behavior Driven
Development
Best Practices
Also
Wichtig ist
Ist glaube ich eben
Dass man sich überlegt
Auf welcher Ebene
Formuliert man das Ganze
Und dann
Zum Beispiel
Bilde ich
Verschiedene
Seiten
Meiner Web-Anwendung
Durch URLs ab
Oder bilde ich die
Durch Begriffe ab
Login-Seite
Hauptseite
Willkommensseite
Und so fort
Wie gehe ich damit um
Was bringt das für mich
Für Vor- oder Nachteile
Das hängt auch immer
So ein bisschen davon ab
Was die Frameworks
Jeweils dann für Möglichkeiten
Bieten um vielleicht
Aliasse zu definieren
Und solche Dinge mehr
Ähm
Also
Ich muss mir Gedanken machen
Wie ich
Wie ich meine Testfälle
Auf verschiedene Dateien aufteile
Darüber haben wir noch
Gar nicht gesprochen
Das sind ja immer
Textdateien
Oder das ist der übliche Fall
Das sind einfach Textdateien
Und es bietet sich dann häufig an
Einzelne Dateien auszuführen
Wenn ich mir jetzt vorstelle
Ich habe eine riesen Test-Suite
Mit ein paar hundert
BDD-Testfällen
Das kann schon mal
Erklägliche Zeit dauern
Bis die mal durchgeraten sind
Und dann macht es natürlich Sinn
Sich da schöne
Teilmengen zu überlegen
Zu sagen
Okay
Das da ist
Keine Ahnung
Dieser Microservice
Oder
Das da sind
Genau die Funktionen
Die momentan gerade heiß sind
Oder
Das sind die besonders
Wichtigen Kernfunktionen
Die müssen
Auf alle Fälle gehen
Oder sowas
Da
Gibt es also
Ähm
Best Practices kann ich jetzt nicht gut formulieren
Insbesondere nicht in einem Podcast
Da werden einfach alle irre
Wenn ich jetzt anfange
Irgendwie Pfade runterzurattern
Oder sowas
Aber das sind halt so
So Dinge mit die man
Die man im Hinterkopf haben muss
Wenn man sich überlegt
Wie baue ich
Meine Tests konkret auf
Und das ist genau der Grund
Aus dem ich sage
Es empfiehlt sich da einfach
Sich mal mit jemandem zu unterhalten
Der das schon mal gemacht hat
Und der da irgendwie
Fast grundsätzlich
Auch schon mal auf die Fresse geflogen ist dabei
Ähm
Damit man
Diese Fehler nach Möglichkeit
Ähm
Nicht macht
Mhm
Gut
Man kann natürlich mit Leuten reden
Die das schon gemacht haben
Direkte Erfahrungen gesammelt haben
Oder auch
Ähm
Vielleicht
In der Literatur ein Stück
Nachschlagen
Gibt es denn
Aus deiner Sicht
Beispiele
Bücher
Ähm
Andere Quellen
Die sinnvoll sind
Über die man
Ähm
Sich das Thema
Ein Stück näher bringen kann
Ja also
Das klassische Buch dazu
Ist glaube ich
Ähm
Specification by example
Von Gojko Adzic
Ähm
Ähm
Liest sich ganz gut
Ist auch nicht allzu dick
Das sind
Lass mich lügen
180 Seiten oder so
Ähm
Das ist wirklich
Eine schöne Einführung
In das Thema
Ansonsten
Ähm
Lustigerweise
Das kann man vielleicht auch sagen
Das ist
Das scheint so stark
Abhängig von der jeweiligen
Ähm
Von
Von der jeweiligen
Vertikalen zu sein
In der man unterwegs ist
Wie stark BDD
Genutzt wird
Das scheint im Banken
Und Versicherungssektor
Recht weit verbreitet zu sein
Ähm
Ähm
Aber in anderen Sektoren
Zum Beispiel nicht so sehr
Insofern
Ähm
Wenn man Glück hat
Findet man da auch schon
Kollegen in eigenen Unternehmen
Die das mal ausprobiert haben
Und äh
Bei denen man sich dann
Erfahrungen abholen kann
Ansonsten kann man natürlich auch
Ähm
Sich Hilfe von außen holen
Vielleicht
Kann ich an der Stelle
Kurz erwähnen
Ähm
Ja
Auch
Auch Vampure bietet dazu
Ähm
Kurse und Workshops an
Und äh
Und Beratung
Genau
Aber
Um das wirklich nochmal abschließend zu sagen
Ich wünschte
Mehr Leute würden es verwenden
Weil ich find’s
So ein tolles Werkzeug
Und es ist eigentlich
Nicht so aufwendig
Damit anzufangen
Und man kann ja auch
Man kann ja erstmal echt
Kleine Brötchen backen
Dann machst du halt mal
Nur fünf Testfälle
Das sind immer noch
Das sind immerhin noch
Fünf mehr als gar nix
Und das ist
Und die können
Einem so viel
Sicherheit geben
Auf dieser Ebene
Des Gesamtsystems
Und dann kann man ja
In aller Ruhe
Erfahrungen sammeln
Und kann in aller Ruhe
Herausfinden
Wofür eine
Da die goldene Mitte liegt
Na wie viele
BDD Testfälle
Möchte ich denn eigentlich
Ganz gerne haben
Wie viele
Funktionale Tests
Möchte ich gerne haben
Wieder na
Die Testpyramide
Wie dick will ich dann
Die Spitze von der Pyramide machen
Und dann
Ja so dick
Dass sie halt auch noch
Getragen werden kann
Von dem Rest
Und weiter gepflegt werden kann
Wo sind denn
Bei größeren Produkten
Die Grenzen
Wie viele
BDD
Testfälle
Sind denn noch
Handelbar
Also das
Für komplexe Produkte
Bei Organisationen
Die es damit ernst meinen
Da kann das auch mal
In die Tausende gehen
Na wenn man
Mittelprächtige
Irgendwie Anwendung hast
Und du machst das
Wirklich
Systematisch
Du lädst deine
Deine
Fachleute ein
Deine
Abteilungsexperten ein
Jeder gibt da
Seinen Senf dazu
Und gießt
Na jede
Jede
Jede beliebige
Verhaltensweise
So wie es ja üblich ist
Dann in
Eine Mehrzahl von Testfällen
Dann habe ich immer
Meinen Happy Path
Und dann habe ich noch
Verschiedene Fehlerfälle
Und so
Das geht ruckzuck
Aber
Ich finde es ist eben auch
Überhaupt keine
Schadensfälle
Schande zu sagen
Wir machen das wirklich
Nur als Smoke Test
Wir machen uns da
Beispielshaft
Fünf
Happy Paths
Und wir weisen uns nach
Dass wenigstens
Die
Weiterhin
Zucken
Und alles andere
Machen wir auf niedrigeren
Ebenen
Wie viel Pflegeaufwand
Steckt denn in so einer
Test Suite
Für Behavior Driven
Development
Ähm
Ähm
, häufig
Lass mich zweiteilen
Ähm, auf der Code-Ebene
Auf der Ebene der Testimplementierung
Ist der Aufwand häufig
Überraschend gering
Weil es sind nämlich häufig
Gar nicht so viele
Wenn du eine Web-Anwendung hast
Schlussendlich so viele
Verschiedene Interaktionen
Mit der hast du ja gar nicht
Halt auf vielen verschiedenen Seiten
Und in vielen verschiedenen Kontexten
Aber ein Textfeld ist ein Textfeld
Und ein Button ist ein Button
Fertig, ne?
Wenn ich einmal den Code habe
Um Buttons zu klicken
Dann kann ich halt
Alle tausend Buttons
Auf meiner Webseite klicken
Das ist also vergleichsweise
Überschaubar häufig
Wo häufig der Teufel drinsteckt
Ist
In der Spezifikation
Und zwar nicht nur
In den einzelnen Spezifikationen
Wie die verfasst sind
Sondern vor allen Dingen
In ihrem Zusammenhang
Ob die weiterhin
In ihrer Struktur
Gut zusammenpassen
Ob die sich vernünftig
Testen lassen
Ähm
Dass ich da den
Zwischen den
Ausrüstungs-
Also Aufwand
Akzeptabel halte
Um mir eine neue
Testumgebung zu bauen
Und so
Da kann also ganz viel
Refactoring-Aufwand
Drin stecken leider
Und deswegen ist es halt
Auch so kritisch
Dass man sich da
Ein gutes System überlegt
Ähm
Dass einem da
Die Möglichkeit
Weiterhin offen lässt
Sich auch mal zu verändern
Weil das wird passieren
Hm
Gut
Wir sind letztendlich
Oh ziemlich
Am Ende der
Geplanten
Länge
Der Session
Ähm
Ähm
Ähm
Ähm
Ähm
Ähm
Ähm
Ähm
Ähm
Hast du noch
Punkte
Die wir bis jetzt
Nicht besprochen haben
Die du gerne noch
Reden möchtest
Oder noch
Ein Hinweis
Auf eine Quelle
Geben
Oder irgendwas
Was hilfreich ist
Für
Jemanden
Der sich
Weiter mit dem
Thema
Behavior-Driven
Development
Befassen möchte
Also
Vielleicht als
Als weiteren
Literatur-Hinweis
Im weitesten Sinne
Ich finde
Zum Beispiel
Die Wikipedia-Seite
Über
Behavior-Driven
Development
Ganz gut gemacht
Die hat ein paar
Schöne Beispiele
Und
Ähm
Und das Witzige
Bei BDD ist
Das ist so
So schlank
Irgendwie
Ähm
Damit ist dann schon
Schier alles gesagt
Also auch
Das Buch von
Gojko Adzic
Zum Beispiel
Das hält sich mal
Kurz drei Seiten
Damit auf dir zu sagen
Also es gibt dann
Ein Given
Und ein When
Und ein Then
Plus extra Würste
Und sich dann
Den Rest des Buches
Damit aufhält
Zu sagen
Und so macht man es richtig
Und so sollte man es
Besser nicht machen
Und
Wie gesagt
Probiert es aus
Ähm
Es soll euer Schaden
Nicht sein
Und wie gesagt
Ich ändere nochmal
An mein Eingangsbeispiel
Wir hatten
Ein Produkt
Wo wir nur
Einen einzigen Test hatten
Es war also
Fast ein bisschen
Übers Ziel hinausgeschossen
Dass wir das als BDD
Formuliert haben
Aber es war einfach
Hilfreich für uns
Damals auch zu durchdenken
Was
Was wollen wir denn
Was soll das Ding denn machen
Und dann hatten wir schon
So formuliert
Dann haben wir es direkt
So gelassen
Ähm
Das ist so machtvoll
Diese
Diese Sicherung
Im Rücken zu haben
Dass man sagt
Ganz grundsätzlich
Kann ich das Gesamtsystem
Automatisiert
Durchtesten
Okay
Dann
Würde ich sagen
Vielen Dank
Für
All deine
Gedanken und Beiträge
Ich hoffe
Unsere
Hörer interessieren sich
Auch für
Ähm
Das Thema BDD
Dadurch mehr als zuvor
Gibt vielleicht
Eine Anregung
Für den einen oder anderen
Es wirklich zu tun
Ähm
Du hast erwähnt
Die Wikipedia-Seite
Du hast das
Äh
Die Schulungen und Workshops
Die es bei
Bei Vampio
Also unter
Vampio.de
Ähm
Gibt
Ähm
Wenn ihr
Feedback
An uns habt
Könnt ihr natürlich auch gern
Über den Weg
Mit uns in Kontakt
Treten
Uns Hinweise geben
Vielleicht habt ihr auch mal Lust
In ähm
Dem Podcast
Mit aufzutreten
Und ähm
Ganz andere Stich
Äh
Ganz andere Sichtweisen
Ähm
Vielleicht mit uns zu diskutieren
Ähm
Kommt auf uns zu
Wir freuen uns darauf
Und ähm
Wünschen euch
Bis zur nächsten Folge
Eine gute Zeit
Vielleicht mit BDDs
Genau
Also vielen Dank fürs Zuhören
Macht’s gut
Bis bald
Ciao
Ciao
Ciao