Behavior Driven Development

Copyright ┬ę Shutterstock / Alexander Supertramp

Bei der agilen (beweglichen) Softwareentwicklung stehen selbstorganisierte Teams sowie inkrementelle und iterative Vorgehensweisen im Vordergrund. Durch die moderne Art von Softwareentwicklung soll der Entwicklungsprozess schlanker und flexibler werden als bei den klassischen Modellen. Eine der wichtigsten Techniken, die im Rahmen der agilen Softwareentwicklung zum Einsatz kommt, ist die verhaltensgetriebene Softwareentwicklung.

Was ist Behavior Driven Development?

Das Behavior Driven Development (BDD) wird oftmals als anforderungsgetriebene Softwareentwicklung (Specification Driven Development) (SDD) bezeichnet. Bei dieser agilen Softwareentwicklungstechnik steht die Zusammenarbeit zwischen dem Qualit├Ątsmanagement und der Business-Analyse im Vordergrund und diese soll in den Softwareentwicklungsprojekten gest├Ąrkt werden.

Behavior Driven Development – Geschichte und Bedeutung

Das Behavior Driven Development wurde zum ersten Mal im Jahr 2003 von Dan North in Form einer Antwort auf die testgetriebene Entwicklung ├Âffentlich beschrieben. Seit dieser Zeit hat sich die verhaltensgetriebene Softwareentwicklung nach und nach weiter entwickelt. Dan North hat das BDD nicht nur erstmals erw├Ąhnt, er hat das erste Framework (Programmierger├╝st in der Softwaretechnik) mit dem Namen “JBehave” f├╝r die praktische Umsetzung des Behavior Driven Development entwickelt.

Das BDD zeichnet sich dadurch aus, dass bereits w├Ąhrend der Analyse der Anforderungen die sp├Ąteren Ziele, Aufgaben und die Ergebnisse der jeweiligen Software in einer festgelegten Textform notiert werden. Auf Basis dieser Anforderungen werden im Anschluss daran die automatisierten Tests durchgef├╝hrt, damit das Programm im Hinblick auf eine korrekte Implementierung umfangreich getestet werden kann. Die Anforderungen an die Software werden in der Regel in sogenannten “Wenn-dann-S├Ątzen” festgehalten und diese basieren auf der ubiquit├Ąren Sprache vom Domain-driven Design. Dadurch soll ein ├ťbergang von der menschlichen Sprache der Definition der jeweiligen Anforderungen zu der technischen Programmiersprache deutlich erleichtert werden. Dank dieser Erleichterungen sollen die Anforderungen in der Programmiersprache besser umgesetzt werden k├Ânnen.

Die agile Softwareentwicklung orientiert sich stets an dem Verhalten, welches ein beliebiges Produkt in der Praxis zeigen soll. Den Softwareentwicklern stehen zu diesem Zweck verschiedene Tests zur Verf├╝gung. In einem solchen Test lassen sich die fachlichen Anforderungen an die Software definieren, sodass die Entwickler die jeweiligen Anforderungen genau nachvollziehen k├Ânnen. Sowohl f├╝r die sp├Ąteren Nutzer der Software als auch f├╝r die Auftrag- oder Geldgeber ist das Nachvollziehen der Anforderungen deutlich schwieriger. Aus diesem Grund fokussieren sich die Entwickler beim Behavior Driven Development auf das Verhalten einer Software. Dadurch k├Ânnen sie die daraus entstehenden Anforderungen, auftretende Probleme und die technische Umsetzung in Testf├Ąllen auf viele andere Systeme ├╝bertragen. Diese Merkmale spiegeln das Verhalten einer Software individuell wieder und k├Ânnen in vielen unterschiedlichen Test-, Entwicklungs- und Produktivumgebungen anderen beteiligten Personen gezeigt werden.

Beim Behavior Driven Development werden im direkten Vergleich zu herk├Âmmlichen Modellen keine austauschbaren Testmethoden definiert, stattdessen wird das Verhalten einer Software konkret beschrieben. Dadurch k├Ânnen alle Beteiligten an den Projekten den Sinn und Zweck der Tests ohne Probleme nachvollziehen. Die Fokussierung auf das individuelle Verhalten von einem Programm ist im Hinblick auf den Gesch├Ąftswert von Vorteil, den eine entwickelte Software f├╝r den Auftraggeber bzw. das Unternehmen darstellt. Macht eine Webanwendung oder eine Software in der Praxis nicht genau das, was sie tun soll, so sind die gesch├Ąftlichen Ziele von einem Unternehmen nicht erreicht. Tut das Programm genau das, was es soll, so sind die Gesch├Ąftsziele entweder teilweise oder vollst├Ąndig erreicht.

Aus diesem Grund profitieren vom modernen Behavior Driven Development nicht nur die Entwickler von einer Software, sondern alle beteiligten Personen. Durch den direkten Fokus auf das jeweilige Verhalten von einem Programm entsteht ein direkter Bezug zu den jeweiligen inhaltlichen Merkmalen der Softwareentwicklung. Ein Programmierer wei├č genau, was seine Software in der Praxis tun soll und h├Ąlt ihre Funktionen ausf├╝hrlich in den jeweiligen Anforderungskatalogen fest. Selbstverst├Ąndlich hat ein Entwickler einen direkten und privilegierten Zugang zu der Material. Diesen Zugang haben andere Beteiligte an dem Projekt, wie beispielsweise die Qualit├Ątssicherung oder das Projektmanagement nicht.

Das Behavior Driven Development schafft bei diesem gro├čen Unterschied Abhilfe. Zu diesem Zweck wird die technische Dokumentation der Tests in eine nat├╝rliche Sprache ├╝bersetzt. Diese k├Ânnen nicht nur Entwickler, sondern auch alle anderen Beteiligten lesen. Das Qualit├Ątsmanagement und die Projektleitung k├Ânnen anhand dieser technischen Dokumentation sofort feststellen, welche Voraussetzungen die Software sp├Ąter erf├╝llen muss. Im Gegensatz zur klassischen Herangehensweise ben├Âtigen die Beteiligten somit nicht mehr ein hohes technisches Verst├Ąndnis, um die fachlichen Zusammenh├Ąnge zu verstehen.

Tipp

Durch das Behavior Driven Development wird es f├╝r alle beteiligten Personen deutlich einfacher zu verstehen, was eine Software leisten soll und welche Voraussetzungen sie im Praxiseinsatz erf├╝llen muss. Die Programmierung und alle Arbeiten an einem Programm lassen sich mithilfe der ubiquit├Ąren Sprache von jeder beteiligten Person bis ins kleinste Detail nachvollziehen. Die Architektur des Programms besitzt zudem einen direkten Bezug zu der Dom├Ąne, in der die Software sp├Ąter laufen soll. Das Domain-Driven Design ist vollkommen unabh├Ąngig von Werkzeugen, Frameworks und allen g├Ąngigen Programmierparadigmen. Dennoch wird das Design oftmals im direkten Zusammenhang mit der objektorientierten Programmierung eingesetzt.

Aus welchen Elementen besteht das Behavior Driven Development?

Als eine wichtige Technik, die im Rahmen der agilen Softwareentwicklung zum Einsatz kommt, besitzt das Behavior Driven Development spezielle Eigenschaften. Im direkten Vergleich zu herk├Âmmlichen Entwicklungstechniken gibt es gleich mehrere Vorz├╝ge und das BDD schafft zus├Ątzliche M├Âglichkeiten. Unter dem Strich ist es f├╝r alle Beteiligten von Vorteil, wenn das Behavior Driven Development zum Einsatz kommt. Grunds├Ątzlich besitzt das Behavior Driven Development besondere Eigenschaften, besteht aus mehreren Elementen und folgt einem bestimmten Ablauf. Eine wichtige Rolle spielt das TDD (Test Driven Development). Bei der testgetriebenen Entwicklung geht es vor allem darum, dass sich die Entwickler w├Ąhrend der Implementierung einer Software sich mit ihren eigenen Tests unterst├╝tzen und treiben lassen k├Ânnen. Besonders wichtig ist die Outside-In-Softwareentwicklung, denn die Tests sollen von au├čen ├╝ber eine ├Âffentliche Schnittstelle erfolgen. Aufgrund dessen werden alle Beteiligten stark mit in den Entwicklungsprozess vom Behavior Driven Development einbezogen und k├Ânnen die einzelnen Entwicklungsschritte leichter nachvollziehen. Das Ziel ist das Erf├╝llen der jeweiligen Anforderungen der sp├Ąteren Nutzer oder der Auftraggeber.

Durch praktische Fallbeispiele wird das Verhalten einer Software samt dem jeweiligen Verhalten der einzelnen Softwareteile textuell beschrieben. Zum Einsatz kommen genormte Schl├╝sselw├Ârter und mit diesen werden alle Vorbedingungen, das gew├╝nschte und das externe Verhalten gut sichtbar markiert. Die praktischen Fallbeispiele werden mittels speziellen Mock-Objekten (Attrappen in der Softwareentwicklung) automatisiert und k├Ânnen zur Simulation der noch nicht integrierten Softwareteile verwendet werden. Im Anschluss daran erfolgt eine sukzessive Implementierung aller bisher noch nicht integrierten Teile. Zu diesem Zweck werden alle bisherigen Attrappen durch die jeweiligen Softwareteile ersetzt. Durch diesen Prozess entsteht eine leicht pr├╝fbare Beschreibung der Software und anhand dieser l├Ąsst sich zu jeder Zeit ├╝berpr├╝fen, ob die umgesetzten Softwareteile korrekt sind. Besonders wichtig bei diesem Vorgang ist es, dass die jeweilige Beschreibung nicht f├╝r die Implementierung einer Anwendung verwendet wird, sondern dem Zweck der jeweiligen Anwendung dient.[/accordion]

Welche Werkzeuge kommen zum Einsatz?

Beim Behavior Driven Development kommen, wie bei jeder anderen Art der Softwareentwicklung, verschiedene Werkzeuge (Frameworks) zum Einsatz. Diese Werkzeuge werden f├╝r das jeweilige Verhalten in verschiedenen Szenarien programmiert und eignen sich in der Regel f├╝r eine bestimmte Programmiersprache. Zu den bekanntesten Werkzeugen im Bereich vom Behavior Driven Development geh├Âren Java sowie JavaScript, FIT (Framework for Integrated Test), RBehave, JBehave, FitNesse, Cucumber f├╝r Ruby und Concordion f├╝r Java. Die Umsetzung der Attrappen (Mock-Objekte) erfolgt entweder manuell von Hand oder ├╝ber spezielle Frameworks wie EasyMock oder Mockito. Die Objekte werden nicht nur zum Ersetzen von Teilen der Software ben├Âtigt, sie sind auch bei der direkten Entwicklung der Tests hilfreich.

Praktische Beispiele f├╝r das Behavior Driven Development

Die Anforderungen an eine Software werden mittels Szenarios beschrieben. In der Regel erfolgt diese Beschreibung in einem bestimmten Format. Dadurch l├Ąsst sich eine automatisierte ├ťberpr├╝fung der Beispiele leicht umsetzen. Eines der g├Ąngigen Formate beim Behavior Driven Development ist die bekannte Beschreibungssprache Gherkin. Diese kann sowohl mit deutschen (gegeben, wenn, dann, und) als auch mit englischen Schl├╝sselw├Ârtern (given, when, then, and) erfolgen. Weitere Sprachen sind ebenfalls m├Âglich. Die praktische Umsetzung l├Ąsst sich anhand folgendem Beispiel verdeutlichen:

Szenario: Ein zur├╝ckgegebenes Produkt kehrt wieder in das Lager zur├╝ck

  • Gegeben ist, dass ein Kunde einen schwarzen Rucksack gekauft hat
  • Und es befinden sich 5 schwarze Rucks├Ącke im Lager
  • Wenn der K├Ąufer den Rucksack zur├╝ckgibt, erh├Ąlt er eine Gutschrift
  • Dann Befinden sich 6 schwarze Rucks├Ącke im Lager

Dieses Beispiel illustriert den spezifischen Verhaltensaspekt einer Software. Alle Beteiligten an einem Projekt sollten sich fragen, ob das Ergebnis von einem Szenario stets in einem zu vorgegebenen Kontext auftritt. Ist dies der Fall, so lassen sich weitere Beispiele zur Kl├Ąrung der jeweiligen Anforderung erstellen. Anhand des oberen Beispiels k├Ânnte ein Beteiligter mit Fachwissen erkennen, dass der zur├╝ckgegebene Rucksack nur in das Lager kommt, wenn er keine Fehler hat. Entsprechend seines Wissens m├╝sste das Beispiel erg├Ąnzt werden. Mit den Schl├╝sselw├Ârtern gegeben, wenn, dann, und lassen sich die Szenarien beim Behavior Driven Development verdeutlichen, sie sind jedoch keine Pflicht.


Sie haben noch Fragen?

Kontaktieren Sie uns

Kostenloser SEO-Check der OSG


Weitere Inhalte