Was ist BDD (behavior-driven development)?

In der Tech-Welt ist Behavior-Driven Development weithin unter der Abkürzung BDD oder dem Spitznamen "Specification by Example" weithin bekannt und wird allgemein definiert als "eine Methodik zur Entwicklung von Software durch kontinuierliche, beispielbasierte Kommunikation zwischen Entwicklern, QAs und BAs." BDD wurde von einem Mann namens Dan North entwickelt und ist seine Antwort auf die Frustration, nicht klar erklären zu können, wann Entwickler wissen wollten, wo sie anfangen sollten, was nicht getestet werden sollten, wie viel getestet werden sollte, wie die Tests genannt werden sollten und wie man versteht, warum ein Test fehlschlägt. Diese Methodik, die aus Test Driven Development (TDD) und Acceptance Test-Driven Development (ATDD) hervorgeht, wird verwendet, um Agilität, konkrete Kommunikation und ein gemeinsames Verständnis der Ziele zwischen Teams, technisch und nicht-technisch, zu schaffen.

Im Wesentlichen ist es der kollaborative Prozess, bei dem auf sehr direkte, beispielbasierte Weise eine Reihe von Verhaltensweisen beschrieben werden, die von einem System erwartet werden können – letztlich ist das Ergebnis, dass alle Beteiligten kraftvolle Gespräche darüber führen können, was die Software tun soll. Darüber hinaus werden bei korrekter Umsetzung alle Teams die Funktionalität der Lieferergebnisse ohne Verwirrung verstehen und Schlüsselergebnisse erkennen können, bevor der Entwicklungsprozess überhaupt beginnt. Im folgenden Artikel werden wir die Feinheiten von BDD sowie Beispiele beleuchten, wie man es in die Methodik des Softwareentwicklungsmanagements Ihrer Organisation integrieren kann.

Der kollaborative Softwareentwicklungsansatz von BDD funktioniert gut mit den kurzen Sprints, kontinuierlichem Feedback und iterativen Ansatz zur Verbesserung agiler Methoden. Die eine ersetzt die andere nicht, sondern sie ergänzen sich, um sich gegenseitig zu verbessern. BDD bietet agilen Prozessen eine strukturierte, menschenlesbare Möglichkeit, Anforderungen zu definieren und Szenarien sowie Benutzerinteraktionen zu beschreiben, sodass Entwickler ein kundenorientiertes, geschäftsorientiertes, praxisnahes Verständnis dessen haben, was die Software leisten muss.

Eine Möglichkeit, sich BDD vorzustellen, ist eine Sammlung von Plugins zur Verbesserung Ihrer agilen Prozesse. Wenn BDD und Agile integriert werden, kann Ihre Organisation schnell reagieren, wenn sich die Bedürfnisse ändern, um das agile Versprechen zuverlässig funktionierender Software bei Bedarf zu erfüllen, während die Wartung unterstützt und Teams fokussiert und diszipliniert bleiben.

BDD ist ein Prozess aus drei Schritten, die kontinuierlich und wiederholt ablaufen, um kleine und handhabbarere Änderungen zu ermöglichen. Die Idee ist, diese Schritte schnell zu durchlaufen, die Erfolge so zu dokumentieren, dass sie wiederholbar sind, und den Prozess mit jeder Iteration zu stärken.

BDD in Agile

BDD-Prozess

• Entdeckung: Der Prozess beginnt mit der Entwicklung der "User Story", die beschreibt, was der Nutzer tun muss, welche Funktionen er benötigt, Prioritäten und mögliche Verständnislücken. Das Ziel ist eine gegenseitige, vollständige und detaillierte Vorstellung von Bedürfnissen und deren Gründen. In BDD haben diese Geschichten eine Struktur, wie Sie in den Beispielen sehen werden.
• Formulierung: Der nächste Schritt besteht darin, die Erkenntnisse aus den User Stories zu dokumentieren und im Grunde den Nutzern und anderen wichtigen Stakeholdern das zurückzugeben, was die Entwickler verstehen. Formulierungen sind ausführbare Spezifikationen, die für Feedback und Überarbeitung geteilt werden können. Das Ergebnis ist eine gemeinsame, gegenseitig verstandene Vision davon, was gebaut werden soll.
• Automatisierung: Dies ist die Phase, in der die Softwarespezifikationen in Code als ausführbare Testszenarien implementiert werden, die beschreiben, wie das System funktionieren soll, in menschenlesbarer Sprache. Diese Szenarien oder automatisierten Beispiele erleichtern das Verständnis der Software.

Der Prozess legt den Schwerpunkt auf kleine Änderungen, schnelle Iteration und kontinuierliche Wertsteigerung des Systems, während man bereit ist, auf Feedback zu reagieren.

Beschleunigung von TDD und ATDD durch BDD

Um BDD zu verstehen, müssen Sie zunächst mit den Bedeutungen von TDD und ATDD sowie deren Verwendung vertraut gemacht werden. Anschließend müssen Sie verstehen, wie BDD diese beiden Methoden beschleunigt, indem es ihre Grundprinzipien zu einem leistungsstarken Softwareentwicklungsprozess vereint.

TDD "bezeichnet einen Programmierstil, in dem drei Aktivitäten eng miteinander verflochten sind: Programmierung, Testen (in Form von Unit-Tests) und Design (in Form von Refactoring)." Wenn diese Methodik verwendet wird, muss ein Entwickler zunächst einen Testsatz für eine bestimmte Einheit definieren, dann absichtlich zum Scheitern bringen, dann die Einheit einsetzen und anschließend bestimmen, ob die Einheit erfolgreich war. Ein sehr wichtiger Bestandteil des Erfolgs von BDD ist, dass ein Programmierer die TDD-Struktur kennen und innerhalb dessen arbeiten sollte, bevor er BDD lernt oder implementiert.

ATDD "beinhaltet Teammitglieder mit unterschiedlichen Perspektiven (Kunden, Entwicklung, Testing), die zusammenarbeiten, um Akzeptanztests zu schreiben, bevor die entsprechende Funktionalität implementiert wird. Die kollaborativen Diskussionen, die zur Erstellung des Akzeptanztests stattfinden, werden oft als die drei Amigos bezeichnet – sie repräsentieren die drei Perspektiven von Kunden (welches Problem versuchen wir zu lösen?), Entwicklung (wie könnten wir dieses Problem lösen) und Testen (was ist mit...)." Jeder Test innerhalb dieser Methodik sollte im Stil "gegeben, wann, dann" oder if-then-Format geschrieben werden, wie unten:

Gegeben [Anfangskontext]

Dann [sichere einige Ergebnisse]

Mit dem ersten Fokus auf der Verkürzung der Gesamtentwicklungszeit sowie der Anzahl der durch Tests auf allen Anforderungsstufen gefundenen Fehler und stärkeren Codebasen, konzentriert sich der zweite auf die Vereinfachung der Kommunikation über ein domänenspezifisches Sprachformat und die Zusammenarbeit jeder Endergebnisperspektive, und in Kombination erhalten wir BDD. Ausgehend von dem, was wir oben wissen – dass BDD eine beispielgetriebene Kommunikationsmethodik ist, die über Anwendungsverhalten spricht – nutzen BDD-Grundprinzipien im Kern die Gesprächsstruktur, die auch Nicht-Entwickler aus ATDD verstehen können, in Verbindung mit einem eingegrenzten TDD-Testfokus, der auf Verhaltensmerkmale abzielt, die am besten in geschäftsgetriebener Logik beschrieben werden.

Die 2 Grundprinzipien

Klar geschriebene Szenarien, die die Absicht, das Wer und das Was beschreiben, das passieren sollte, um die Anforderungen der Einheit zu erfüllen. Innerhalb von BDD müssen User Stories sehr spezifisch sein und immer ganze Sätze einschließlich Namen/Funktion umfassen. Bei der Einführung der Methode sagte Dan North : "Entwickler entdeckten, dass sie zumindest einen Teil ihrer Dokumentation für sie übernehmen konnte, also begannen sie, Testmethoden zu schreiben, die echte Sätze waren. Außerdem stellten sie fest, dass die generierten Dokumente für Geschäftsnutzer, Analysten und Tester Sinn ergaben, wenn sie den Methodennamen in der Sprache der Geschäftsdomäne schrieben." Idealerweise verwendet man das Wort "sollte" und im Wenn-dann-Format, verlangt BDD technisch gesehen kein spezifisches Szenarioformat. Viele Experten, darunter Dan, empfehlen jedoch, dass Ihre Organisation mit einem standardisierten Format arbeitet. So können Teams jetzt und in Zukunft problemlos modifizieren, erforschen und erweitern.

Dan Norths User Story-Format 

Titel (eine Zeile, die die Geschichte mit 'sollte' beschreibt)

Annahmekriterien: (präsentiert als Szenarien)

Und [noch etwas mehr Kontext]...

Und [ein weiteres Ergebnis]...

Um Ihnen zu helfen, das Aussehen mit leichten Formatvariationen besser zu verstehen, hier ein API-Testbeispiel aus Guru:

Funktion: Test-CRUD-Methoden im Beispiel eines REST-API-Testframeworks

Vorausgesetzt, ich setze Beispiel-REST API URL

Szenario: Beispiel eines POST-Beitrags

Da I Set POST posts API-Endpunkt gesetzt

Wenn ich den HEADER-Param-Anfrage-Content-Typ als "application/JSON" setze.

Und Set-Request-Body

Und sende eine POST-HTTP-Anfrage

Dann erhalte ich den gültigen HTTP-Antwortcode 201

Und Antwort BODY "POST" ist nicht leer.

Szenario: Beispiel für GET-Beiträge

Gegeben, ich setze GET posts, API-Endpunkt "1"

Wenn ich den HEADER-Param-Anfrage-Content-Typ als "application/JSON" setze.

Und sende eine GET-HTTP-Anfrage

Dann erhalte ich den gültigen HTTP-Antwortcode 200 für "GET".

Und der Antwort-KÖRPER "GET" ist nicht leer

Szenario: Beispiel für UPDATE-Beiträge

Da ich den API-Endpunkt für "1" gesetzt habe, setzt ich PUT Posts.

Wenn ich den Update-Request-Body setze

Und sende eine PUT-HTTP-Anfrage

Dann erhalte ich den gültigen HTTP-Antwortcode 200 für "PUT".

Und der Antwort-BODY "PUT" ist nicht leer

Szenario: Beispiel für DELETE-Beiträge

Da ich den API-Endpunkt von DELETE auf "1" gesetzt habe.

Wenn ich eine DELETE-HTTP-Anfrage sende

Dann erhalte ich den gültigen HTTP-Antwortcode 200 für "DELETE".

Wie wir in diesem Artikel schon mehrfach betont haben und gar nicht genug betonen können, setzt BDD stark auf die Verwendung von Sprache, die jedes Teammitglied verstehen kann. Domain-Specific Language (DSL) macht jedes Szenario für Geschäftspartner lesbar, also für diejenigen, die die Software und Tests in Auftrag geben, weil sie wollen, dass ein bestimmtes Verhalten auftritt. Sie beseitigt die Notwendigkeit, sowohl technisch als auch nicht-technisch zu erklären, wie ein Verhalten umgesetzt wird, und sorgt dadurch für weniger Verwirrung während des Prozesses.

Um Zeit und Ergebnisse zu maximieren, wird BDD von Tools unterstützt, die Tests automatisieren. Eng mit dem von Ihrer Organisation definierten DSL verbunden, umfasst diese Tools Cucumber, das Gherkin verstehen kann und gleichzeitig Spezifikationen für 30 gesprochene Sprachen schreibt. Solche Werkzeuge führen bei Verwendung automatisch gängige Sprachspezifikationen aus.

Starten Sie verhaltensgetriebene Entwicklung in Ihrer Organisation

Egal, wo sich Ihre Organisation auf ihrer Softwareentwicklungs-Management-Reise befindet – unter Verwendung agiler Methoden, Wasserfall oder etwas anderes – die Implementierung dieser Methodik bringt einen höheren Gewinn als einen Risikowert. Wenn die Nutzung der Methode nicht zu Ihren Bedürfnissen passt, können Sie einfach wieder die Testanforderungen so formulieren, wie Sie es bisher gemacht haben. Es gibt kein Rückgängigmachen.

Zunächst sollten Sie sicherstellen, dass Ihre Entwickler innerhalb von TDD arbeiten und sie verstehen. Wenn nicht, müssen sie eine Schulungsphase beginnen, um Fähigkeiten in diesem Programmierstil zu entwickeln. Sobald Ihre Entwickler an Bord sind, können Sie die Grundlagen von BDD in Ihrer gesamten Organisation umsetzen. Auch hier muss eine Schulungsphase stattfinden. Während dieser Zeit müssen Entwickler, QA- und BA-Teams lernen, wie sie Ihr gewähltes DSL und die Dokumentationsmethode lesen und verstehen. Beginnen Sie mit nur einem Projekt, um zu sehen, wie alles funktioniert. Beachten Sie, dass diese Methodik vor der Entwicklung Spezifikationen und ständiges externes Feedback von Nutzern, Kunden und Fachexperten erfordert. Wenn Sie jedoch erfolgreich umgesetzt werden, reduzieren Sie Regression und verbessern die Zielkommunikation.

Vorteile der BDD-Software

Die weitverbreitete Nutzung von BDD für die Softwareentwicklung wird durch seine Effektivität bei der Übersetzung von Geschäftsanforderungen in ausführbaren Softwarecode vorangetrieben. BDD bietet:

• Verbesserte Kommunikation: Der Ansatz ermöglicht es allen Beteiligten, ihre Bedürfnisse und Erwartungen in normaler Sprache zu beschreiben, was mit technischem Fachjargon oder Programmiercode unmöglich ist.
• Gemeinsames Verständnis: Da alle Beteiligten, einschließlich nicht-technischer Nutzer und Entscheidungsträger, alle Phasen von Entdeckung, Formulierung und Automatisierung verstehen können, beginnen und werden Projekte mit einem klaren und gemeinsamen Verständnis dessen fortgesetzt, was die Software leisten wird.
• Frühzeitige Erkennung von Problemen: Wenn Sie "nach links verschieben", um frühzeitig durch beispielbasierte Kommunikation Probleme zu testen, zu finden und zu beheben, straffen Sie Zeit, Frustration und Kosten.
• Verbesserte Testabdeckung: Da das Schreiben von Tests so viel einfacher ist, können Sie alle möglichen Szenarien für gründlichere und relevantere Tests abdecken.
• Reduzierte Nacharbeit: Mit besserer Klarheit und Verständnis der Anforderungen passieren weniger Fehler.
• Schnellere Rückkopplungsschleifen: Das Schreiben und Automatisieren von Szenarien mit solidem Testen und Feedback wird mit jeder Iteration einfacher und schneller.
• Abstimmung mit den Geschäftszielen: Da nicht-technische Stakeholder von Anfang an integriert sind, bleibt der Entwicklungsprozess mit den Geschäftszielen übereinstimmend.
• Einfache Wartung: Szenarien leiten nicht nur die Entwicklung, sondern werden zu selbstdokumentierenden Testfällen, sodass es einfacher ist, Softwarefunktionen zu warten und zu aktualisieren.

Häufige Fallstricke des BDD-Ansatzes

Kein Ansatz zur Softwareentwicklung ist perfekt, und das gilt für BDD. Sie können bei der Einführung und Nutzung auf einige Hindernisse und Komplikationen stoßen. Dazu gehören:

• Steile Lernkurve: Sie und Ihre Teams müssen mehr Konzepte kennen, als für TDD nötig ist. Anfänger profitieren davon, Erfahrung mit TDD zu sammeln, bevor sie sich mit BDD beschäftigen.
• Abhängigkeit von Werkzeugen: Es kann dazu neigen, sich auf Werkzeuge zu konzentrieren, ohne genügend Aufmerksamkeit für die Prinzipien und die User Story von BDD zu haben. Behalten Sie den Fokus auf Zusammenarbeit, Kommunikation, gegenseitiges Verständnis und bessere Testabdeckung.
• Konzeptionelle Fehlanpassung: Teams verstehen möglicherweise den zugrundeliegenden Zweck von BDD nicht und betrachten es als Technologie, anstatt es als kollaborativen Ansatz zu sehen. Das Ergebnis kann eine übermäßige Abhängigkeit von Tools und Testframeworks sein, wobei es übersehen wird, dass es im Kern eine Möglichkeit ist, die Kommunikation zwischen Tech- und Nicht-Tech-Stakeholdern zu verbessern.

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.