Die Sprache der Zusammenarbeit: Behavior Driven Developement
BDD steht für Behavior Driven Development, eine Methode zur Softwareentwicklung, die auf dem Prinzip basiert, dass das Verhalten einer Anwendung aus der Perspektive der Nutzer oder Stakeholder beschrieben wird. TDD steht für Test Driven Development, ebenfalls eine Methode zur Softwareentwicklung. TDD basiert auf dem Prinzip, dass zuerst Softwaretests geschrieben werden, die das gewünschte Verhalten einer Anwendung definieren, und nachfolgend der Code geschrieben wird, der diese Tests erfüllt.
BDD als Erweiterung von TDD
Wir sehen BDD als eine Erweiterung von TDD. Es basiert auf der Idee, dass wir zuerst ein Verhalten definieren, das unsere Anwendung erfüllen soll, und dann den Code schreiben, der dieses implementiert.
1 @smoke @itgain
2 Szenario Outline: Account erfolgreich gefunden
3 Gegeben ich bin auf der Login-Seite
4 Wenn ich gültige Daten eingebe
5 Dann sollte ich in die Seite eingeloggt werden
6 Und meine Standardseite angezeigt werden
BDD verwendet eine einfache und verständliche Sprache, um das Verhalten zu beschreiben, das als Gherkin bekannt ist. Gherkin besteht aus Sätzen, die mit Schlüsselwörtern wie Gegeben, Wenn und Dann beginnen. Diese Sätze bilden eine Spezifikation, die sowohl von Entwicklern als auch von Stakeholdern verstanden werden kann. Zum Beispiel:
Diese Spezifikation kann dann mit Testcode verknüpft werden, der das Verhalten ausführt und validiert. Es gibt verschiedene Tools, die Gherkin unterstützen, wie z. B. Cucumber oder SpecFlow.
BDD ist deshalb eine Erweiterung von TDD, weil es den Fokus von den Testfällen auf das Verhalten verschiebt. In TDD schreiben wir zuerst einen Testfall für eine bestimmte Funktion oder Klasse und dann den Code, der diesen Testfall erfüllt. In BDD schreiben wir zuerst ein Verhalten für eine bestimmte Funktion oder Anforderung und dann den Code, der dieses Verhalten erfüllt.
Vor- und Nachteile
Beide Methoden haben ihre Vor- und Nachteile. Wir haben uns für BDD entschieden, weil wir vor allem von seinen Vorteilen überzeugt sind.
So fördert BDD die Kommunikation und Zusammenarbeit zwischen Entwicklern, Testern, Business Analysten und Kunden. Indem wir das Verhalten einer Anwendung in einer natürlichen Sprache beschreiben, die von allen verstanden wird, können wir Missverständnisse vermeiden und sicherstellen, dass alle auf dem gleichen Stand sind.
Zudem hilft uns BDD, den Fokus auf den Wert und den Nutzen einer Anwendung zu legen, anstatt auf die technischen Details. Indem wir das Verhalten einer Anwendung aus der Sicht der Nutzer oder Stakeholder beschreiben, können wir uns auf das Wesentliche konzentrieren und unnötige Funktionen vermeiden.
BDD ermöglicht es uns, eine lebendige Dokumentation zu erstellen, die immer mit dem Code synchronisiert ist. Indem wir das Verhalten einer Anwendung in Form von Szenarien beschreiben, die als Tests ausgeführt werden können, können wir eine Dokumentation erstellen, die nicht nur beschreibt, was die Anwendung tut, sondern auch zeigt, dass sie funktioniert.
Bei der kontinuierlichen Verbesserung unserer Softwarequalität trägt BDD ebenfalls bei. Indem wir das Verhalten einer Anwendung in Form von Szenarien beschreiben, die als Tests ausgeführt werden sollen, können wir Fehler frühzeitig erkennen und beheben, sowie Änderungen leichter implementieren und überprüfen.
Fazit
Der Vorteil von BDD ist, dass es uns hilft, das Richtige zu bauen, nicht nur einfach etwas richtig zu bauen. BDD fördert die Zusammenarbeit zwischen Entwicklern und Stakeholdern, indem es eine gemeinsame Sprache für die Definition und Validierung des Anwendungsverhaltens bietet. BDD hilft uns auch, unsere Anwendung aus der Perspektive des Benutzers zu betrachten und nicht aus der Perspektive des Codes.
BDD hilft auch, die Qualität der Software zu verbessern, indem es die Testabdeckung erhöht und die Wartbarkeit erleichtert.
Wenn Sie an unserer Dienstleistung zu BDD interessiert sind, kontaktieren Sie uns bitte. Wir freuen uns auf Ihre Anfrage.