Erfahren Sie, was BDD ist, wie es Ihnen helfen kann, Ihre Geschäftsziele zu erreichen, und wie Sie verhaltensgetriebene Entwicklung in einem Projekt praktisch anwenden können.
A QUICK SUMMARY – FOR THE BUSY ONES
TABLE OF CONTENTS
Verhaltensorientierte Entwicklung ist eine High-Level-Softwareprojektmethodik, bei der wir die „Outside-In“ -Technik verwenden.
Das bedeutet, dass wir zuerst die äußere Ebene herausfinden, also die Bedürfnisse eines Unternehmens. Dann ermitteln wir die Anforderungen und Funktionen und schließlich erfüllen wir die angegebenen Kriterien, damit unser Produkt funktioniert.
In diesem Artikel erfahren wir, was BDD ist und wie es in einem Projekt verwendet werden kann.
Die Entwicklung von Software oder digitalen Produkten ist zweifellos einer der wichtigsten Bestandteile vieler Unternehmen. Es gibt Techniken, die helfen, den Prozess zu vereinfachen, indem sie die Arbeit in kleinere Aufgaben aufteilen und dann eine Lösung ableiten. In dieser Phase neigen viele Teams dazu, eines der wichtigsten Elemente eines erfolgreichen Projekts zu vergessen, nämlich die Erfüllung der spezifischen Anforderungen eines Unternehmens.
Eine Geschäftsidee kann abstrakt sein und es daher schwierig machen, eine gute Lösung zu finden. Um solche Probleme zu lösen, beginnen wir unseren Entwicklungsprozess immer mit einer Idee. Diese Ideen stellen unser Hauptziel dar und beschleunigen den Softwareentwicklungszyklus.
Im Fall von verhaltensgetriebener Entwicklung besteht unser erster Schritt darin, die gegebene Idee in Anforderungen umzusetzen, die zwischen der äußeren und inneren Ebene liegen (normalerweise als Zwischenebene bezeichnet).
Wenn beispielsweise ein Business Analyst sagt, dass wir unsere Nutzerinteraktion mit dem Produkt um einen bestimmten Faktor erhöhen müssen, müssen wir einen Dienst entwickeln, der es dem Benutzer ermöglicht, nach dem Einloggen auf der Website Feedback zu geben.
Also hier haben wir 2 Anforderungen spezifiziert:
Hier spezifizieren wir auch die Anforderungen so, dass jeder sie verstehen kann. Um diese Flexibilität zu erreichen, erstellen wir eine Storygetriebene Implementierung. Die Geschichte wirkt wie eine natürliche Sprache, die von allen verstanden wird und beschreibend ist und ein erwartetes Ergebnis hat. Es hilft dem Programmierer, das eigentliche Problem zu verstehen.
Die verhaltensgetriebene Entwicklung ist der TDD (Test Driven Development) ziemlich ähnlich, konzentriert sich jedoch auf die Diskussion zwischen den Teammitgliedern.
Wir haben also darüber gesprochen, dass die Geschichte eine entscheidende Rolle in einem Softwareentwicklungszyklus spielt, aber es gibt noch einen anderen Teil von Behavior Driven Development, in dem wir eher Spezifikationen als Geschichten verwenden.
Bei den Spezifikationen konzentrieren wir uns mehr auf Funktionalität eher als die Anwendungsfall von diesem speziellen Problem. Aus offensichtlichen Gründen ist es eher technisch und wird von Geschäftspersonal nicht so häufig verwendet.
Nehmen wir an, wir arbeiten an der Benutzerauthentifizierung. In Bezug auf die Spezifikationen könnten wir über die Felder sprechen, die für die Benutzeranmeldung erforderlich sind. Die Spezifikationen können Name, Passwort, E-Mail usw. sein. Dann besprechen wir, wie Tokens generiert werden sollten und wie sie dann validiert werden müssen, um die Autorisierung zu senden.
Beim Schreiben der Spezifikationen müssen Sie jedoch besonders vorsichtig sein. Sie müssen leicht zu lesen sein. Ihre Tests sollten auch klein sein und nur eine Sache testen und nicht die gesamte Anwendung.
Ihre Tests sollten aus Sätzen bestehen und das von Ihnen verwendete Testframework sollte dies automatisch für Sie erledigen.
Bei Behavior Driven Development besteht unsere Hauptidee darin, die Interaktion zwischen Geschäftsinteressen und technischen Erkenntnissen zu ermöglichen.
Daher werden die Anforderungen in der Regel aus geschäftlicher Sicht generiert und durch technische Lösungen erfüllt. Um die Anforderung zu erfüllen, haben Sie ein gutes Verständnis davon. Daher erstellen wir ein Szenario, in dem wir Folgendes spezifizieren Rolle und Aktion und auf dieser Grundlage prognostizieren wir das Ergebnis. Kurz gesagt, wir erstellen eine User Story mit vordefinierten Aktionen und Ergebnissen.
Das Die Geschichte des Anwenders hilft in vielerlei Hinsicht:
Die „Outside-In“ -Methode ist ein iterativer Prozess. Zunächst erfassen wir möglicherweise die Anforderungen der Benutzer. Auf dieser Grundlage kann ein Business Analyst eine Idee entwickeln und die Anforderungen identifizieren. Jetzt werden Business Analysten die Details mit dem technischen Personal teilen.
Wenn es um die Implementierung von BDD geht, müssen wir einige Regeln befolgen, die vordefiniert sind. Um unsere Geschichte zu schreiben, definieren wir also bestimmte Szenarien und auf dieser Grundlage folgen wir einem Format namens Gewürzgurke Sprache zur Entwicklung unserer Funktionen.
Nehmen wir also ein Beispiel und betrachten wir diese Struktur:
Merkmal: Feedback
Szenario: Ein Benutzer kann sich in die App einloggen
Gegeben: Ich leere die Tabelle „Benutzer“
Und ich erstelle die folgenden Benutzer:
| id | email | benutzername | passwort |
| 1 | [email protected] | Brainhub | zufälliges Passwort |
Wenn ich mich mit dem Benutzernamen „Brainhub“ und dem Passwort „randompassword“ anmelde
Dann bin ich eingeloggt
Hier ist ein typisches User-Story-Format:
Titel: (eine Zeile, die die Geschichte beschreibt)
Erzählung:
Als [Rolle] will ich [Feature]
Also das [profitieren]
Akzeptanzkriterien: (als Szenarien dargestellt)
Szenario 1: Titel
Gegeben [Kontext]
Und [etwas mehr Kontext]...
Wann [Veranstaltung]
Dann [Ergebnis]
Und [ein anderes Ergebnis]...
Um dies zu verstehen, kehren wir zu unserem vorherigen Beispiel zurück. Unser Ziel war es, die Nutzerbindung zu erhöhen. Also haben wir unser Feature hier „Feedback“ genannt und nachdem wir unser Feature definiert hatten, haben wir über Szenarien gesprochen. Szenarien sind Teil einer Geschichte, die eine Aktion spezifiziert und ein Ergebnis erwartet.
Für jeden Szenario wir müssen definieren:
Dies ist nur ein Überblick darüber, wie wir jedes Szenario definieren können. Gleichzeitig kann für jedes Feature mehr als ein Szenario verfügbar sein. Die Struktur, die ich Ihnen gerade gezeigt habe, ist ein Beispiel für Gurke Funktion, bei der es sich um ein auf Gherkin basierendes Tool zur verhaltensgesteuerten Entwicklung für JavaScript handelt. Ebenso gibt es andere Tools für verschiedene Sprachen.
Zum Beispiel haben wir Jasmine für JavaScript-Programmiersprache. Wenn Ihr Code auf eine bestimmte Weise funktionieren sollte, hilft Ihnen Jasmine dabei, diese Absicht im Code auszudrücken. Jasmine hat viele nützliche Funktionen wie verschachtelte Suiten, passende Klassennamen usw.
Eine User Story ist gut, solange es detaillierte Szenarien gibt. Kurz gesagt, man muss alle möglichen Szenarien abdecken, um die Funktionsweise der Software besser zu verstehen. Dies beinhaltet alle mögliche Randfälle.
Ein weiterer wichtiger Punkt ist, dass die Geschichte klein genug sein muss, um iterativ zu sein. Das bedeutet, dass wir das größere Problem in kleinere Teile zerlegen und dann alle kleineren Teile nacheinander in jedem Szenario lösen können, um die Anforderungen zu erfüllen. Auf diese Weise kann ein Geschäftsteam die Arbeit verstehen und den Fortschritt der Entwicklung anhand ihrer Effizienz leicht nachvollziehen.
Sobald wir die Geschichte und die möglichen Szenarien fertiggestellt haben, beginnen wir unseren Softwareentwicklungsprozess, indem wir das Szenario wiederholen und es eins nach dem anderen erfüllen. Mit anderen Worten, die gegebene Software muss bestehe alle Testfälle von uns als Features und Szenarien geschrieben.
Sie fragen sich bestimmt, wie Programmierer diese Funktionen und Szenarien in Testfälle umwandeln. Nun, in den meisten Fällen nehmen sie diese Sätze und ordnen sie Funktionen zu. Sobald diese Testfälle beginnen, werden die abgebildeten Funktionen ausgelöst und die Software wird mit bestimmten Testfällen gestartet.
Letzten Endes geht es bei Behavior Driven Development darum, den gesamten Entwicklungsprozess zu rationalisieren und Mehrwert zu schaffen. Was ist BDD? Es ist nicht nur ein bloßes Toolset. Es ist ein Denkweise. BDD kann Geschäftsanalysten und Testern effektive Methoden beibringen, Anforderungen zu ermitteln, und es kann Entwicklern helfen, qualitativ hochwertigeren und wartbareren Code zu schreiben.
Our promise
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Authors
Full-Stack-Softwareentwickler mit 18 Jahren Berufserfahrung.
Enthusiast für Softwareentwicklung mit 9 Jahren Berufserfahrung in dieser Branche.
Full-Stack-Softwareentwickler mit 18 Jahren Berufserfahrung.
Enthusiast für Softwareentwicklung mit 9 Jahren Berufserfahrung in dieser Branche.
Read next
Popular this month
previous article in this collection
It's the first one.
