Behavior Driven Development


Behavior Driven Development (kurz: BDD; deutsch: verhaltensgetriebene Softwareentwicklung) ist ein Ansatz in der agilen Softwareentwicklung, der aus der testgeleiteten Entwicklung (TDD) entstanden ist und diesen um einen objekt-orientierten Ansatz und das sogenannte Domain-Driven-Design (kurz: DDD; deutsch: domänengeleitetes Design) ergänzt. BDD wird vor allem bei komplexen Softwareprojekten angewandt und vereinfacht die Nutzung von Tools, die zum Testen der Funktionalitäten sowie der Gestaltung der Software und deren Interfaces verwendet werden. BDD kommt zum Beispiel bei der Erstellung von Onlineshops zum Einsatz, ist aber nicht an ein einzelnes Framework oder eine Programmiersprache gebunden. BDD-Tools oder Werkzeuge existieren beispielsweise für Java, JavaScript, Ruby, PHP, Python oder die .NET-Umgebung. Das Ziel der verhaltensgetriebenen Softwareentwicklung besteht darin, die Zusammenarbeit von Entwicklern und des Managements mithilfe einer ubiquitären Sprache zu vereinfachen und dadurch die Migration des Produktes in verschiedene Umgebungen und das Testing zu automatisieren.

Allgemeine Informationen zum Thema

Zentrale Unterschiede zwischen TDD und BDD machen sich bei der Herangehensweise an die Modellierung von Software und Webanwendungen bemerkbar: Während bei der TDD Testfälle vor der Erstellung der Software definiert werden, um die Funktionalitäten später automatisch zu testen, umreißt das Behavior Driven Development zunächst das erwünschte Verhalten der Software aus Sicht eines Anwenders – ähnlich wie die User Stories beim Extreme Programming. Diese Anforderungen werden in einer Sprache formuliert, die die Integration von Aufgaben, Zielen und Resultaten einer Software in verschiedenen Frameworks und Systemen erleichtert und die Methodik des Softwaredesigns leitet.[1]

Die Sprache soll die Umsetzung des gewünschten Verhaltens einer Software mithilfe bestimmter Programmiersprachen so vereinfachen, dass alle beteiligten Entwickler und auch das Management kollaborierend zusammenwirken können. Da die Definition von Testfällen bei der testgeleiteten Entwicklung komplex und für Laien schwer nachvollziehbar sein kann, fungieren die Sprache und der domain-orientierte Ansatz beim BDD als Bindeglieder zwischen den beteiligten Teams und der verwendeten Infrastruktur. Im Zentrum des BDD stehen das Vokabular, das Framework, die Methodik und das, was die Software im Hinblick auf die User Stories realisieren soll.[2]

Funktionsweise

BDD ist durch zwei wesentliche Merkmale gekennzeichnet:[3]

  • Verhalten: Die Softwareentwicklung orientiert sich an dem Verhalten, das das Produkt zeigen soll. Ein Testfall ist jedoch stets nur für den Entwickler einsehbar. Er definiert die fachlichen Anforderungen einer Software so, dass technisch geschultes Personal dies nachvollziehen kann. Aber für die Auftrags- und Geldgeber sowie die Nutzer der Software gilt dies nur bedingt. Durch den Fokus auf das Verhalten der Software werden die Probleme der technisch anspruchsvollen Umsetzung von Testfällen, Anforderungen des Produktes und der Migration auf andere Systeme (Entwicklungs-, Test- und Produktivumgebung) nivelliert. Testfälle, Anforderungen und Domain-spezifische Probleme werden generell als das Verhalten der Software betrachtet. Statt Testmethoden zu definieren, wird das Verhalten der Software beschrieben – so können alle Beteiligten den Sinn und Zweck einzelner Testfälle und User Stories unmittelbar nachvollziehen. Der Fokus auf das Verhalten der Software nützt auch dem Geschäftswert, den eine Software für ein Unternehmen oder eine Gruppe von Auftraggeber bedeutet. Wenn die Software oder Webanwendung genau das macht, was sie soll, sind die Geschäftsziele zumindest teilweise erreicht. Zudem erleichtert der BDD-Ansatz die Erstellung von Dokumentationen, Spezifikationen und APIs.
  • Sprache: Der Fokus auf das Verhalten führt direkt zu den inhaltlichen Merkmalen des BDD. Ein Entwickler weiß, was die Software bewerkstelligen soll und er hält dies in Anforderungskatalogen fest. Allerdings hat der Entwickler einen privilegierten Zugang zur Materie, was für andere Projektbeteiligte wie das Projektmanagement und die Qualitätssicherung nicht gilt. Die Sprache beim BDD schafft hier Abhilfe. Eine technische Dokumentation von Testfällen wird direkt in natürlichsprachliche Elemente übersetzt, sodass auch klar ist, welchen Anforderungen die Software genügen muss – abhängig von den komplexen fachlichen Zusammenhängen der Domäne, auf der das Produkt erstellt wird. Die Arbeit an der Software ist durch die ubiquitäre Sprache für alle Projektbeteiligten bis ins Detail nachvollziehbar und die Architektur der Software (meist Schichtenarchitektur) weist einen direkten Bezug zur Domäne auf, für die die Software erstellt wird. Dabei ist das Domain-Driven-Design unabhängig von bestimmten Programmierparadigmen, Werkzeugen und Frameworks, wird aber meist im Kontext der objektorientierten Programmierung verwendet.

Beispiele

Ein typisches Beispiel zur Verdeutlichung des Behaviour Driven Designs ist die Formulierung eines Szenarios in natürlicher Sprache, die sich an der Fachlogik der Software unmittelbar orientiert. Szenarien werden mithilfe von logischen Standardausdrücken wie Wenn-dann, Und, Oder sowie gegebene Bedingungen näher bestimmt. Jedes Szenario steht dabei für eine abstrakte User Story, die durch die Anwendung ermöglicht wird – etwa ein Login, ein Kauf eines Produktes in einem Onlineshop oder die Datenverwaltung von bestellten Produkten.[4] Das Besondere am BDD ist die Tatsache, dass diese Stories direkt in ausführbare Test via ubiquitärer Sprache übersetzt werden.

Ein Beispiel für ein Login-Vorgang auf einer Website:

  • Gegeben: Ein bestehender Account mit Kundendaten wie Nutzername, Email-Adresse und Passwort
  • Der Kunde loggt sich mit seinen Zugangsdaten in seinen Account ein: Wenn er seinen Nutzernamen und sein Passwort auf der Login-Website eingibt, sollte seine Anmeldung registriert und bestätigt werden. Bei erfolgreichen Login wird eine Bestätigungsseite angezeigt.
  • Wenn die Eingaben nicht korrekt sind, sollte eine Fehlermeldung dargestellt werden und ihm zeigen, was er nicht richtig eingegeben hat.
  • Verschiedene Eventualitäten wie ein Abbruch der Verbindung auf Server- oder Nutzerseite sollten mit disjunktiven Bedingungen verknüpft werden. Schlägt die Kommunikation zwischen Server oder Client fehl, wird eine Fehlermeldung angezeigt.

Je nach verwendeten BDD-Tools und eingesetzten Frameworks werden diese sprachlichen Sätze in ausführbaren Code übersetzt. Zu diesem Zweck sind sie meist in Zeilen von 1 bis X gegliedert und verwenden das Vokabular, das den Übergang der User Story zur Fachlogik des Programms ermöglicht. Gleichzeitig sind durch das Vokabular die anzunehmenden Testfälle hinreichend bestimmt, was das spätere automatisierte Testen der Funktionalitäten der Anwendungen maßgeblich vereinfacht.

Einige Beispiele für BDD-Tools:

  • Gherkin
  • JBehave
  • Cucumber
  • Behat

Bedeutung für die Programmierung

Dan North entwarf die verhaltensgetriebene Softwareentwicklung als Antwort auf die Komplexität des testgeleiteten Designs. Einerseits aus Eigenmotivation, da er sich näher mit diesem wichtigen Thema innerhalb agiler Methoden beschäftigte. Andererseits wollte er den Zugang zu den Vorteilen des Test-First-Ansatzes für Neulinge agiler Methoden erleichtern. Gerade vor dem Hintergrund verschiedener Entwicklungsumgebungen führte das TDD zu Missverständnissen und Konflikten, wenn das Testing nicht umfangreich und korrekt durchgeführt wurde. Die ubiquitäre Sprache, die beim BDD zum Einsatz kommt, und der Fokus auf das Verhalten des Nutzers und somit der Anwendung sollen diese Missverständnisse und Schwierigkeiten minimieren.

Zugleich erhalten das Projektmanagement, die Qualitätssicherung und die Ingenieure, die die Infrastruktur für die Entwicklung aufsetzen, wichtige Hilfestellungen, um die richtigen Entscheidungen treffen zu können.[5] Ähnlich wie bei anderen agilen Ansätze stehen die Abläufe, die eine reibungslose Zusammenarbeit der Projektbeteiligten erforderlich machen, im Zentrum des Designs. Das Verhalten der Anwendung leitet den Designprozess methodisch; die ubiquitäre Sprache übersetzt dieses Verhalten in Elemente, die eine Analyse des Codes sowie nachfolgende Akzeptanz-Tests schon vor dem Fertigstellen der Software antizipieren. Die Automatisierung des Testens kann ebenfalls zu geringeren Gesamtkosten führen.

Einzelnachweise

  1. ↑ TDD vs BDD blog.mattwynne.net. Abgerufen am 28.07.2016
  2. ↑ Was ist Behavior Driven Development? webmasters-fernakademie.de. Abgerufen am 28.07.2016
  3. ↑ Introducing BDD dannorth.net. Abgerufen am 28.07.2016
  4. ↑ What’s in a Story? dannorth.net. Abgerufen am 28.07.2016
  5. ↑ BDD is like TDD if… dannorth.net. Abgerufen am 28.07.2016

Weblinks


Abgerufen von „https://de.ryte.com/wiki/index.php?title=Behavior_Driven_Development&oldid=16098“

Kategorie