Quelltext der Seite Behavior Driven Development

'''Behavior Driven Development''' ('''BDD''', {{deS|verhaltensgetriebene Softwareentwicklung}}), auch als '''Specification Driven Development''' ('''SDD''', {{deS|anforderungsgetriebene Softwareentwicklung}}) bezeichnet, ist eine Technik der [[Agile Softwareentwicklung|agilen Softwareentwicklung]], welche die Zusammenarbeit zwischen [[Qualitätsmanagement]] und [[Business-Analyse]] in Softwareentwicklungsprojekten stärkt. Beim Behavior Driven Development werden während der Anforderungsanalyse die Aufgaben, Ziele und Ergebnisse der Software in einer bestimmten Textform festgehalten, die später als automatisierte Tests ausgeführt werden kann. Damit kann die Software auf ihre korrekte Implementierung getestet werden. Die [[Softwareanforderung]]en werden dabei meist in „Wenn-dann“-Sätzen basierend auf der Sprache des [[Domain-driven Design]]s verfasst. Damit soll der Übergang zwischen der Sprache der Definition der fachlichen Anforderungen und der Programmiersprache, mittels derer die Anforderungen umgesetzt werden, erleichtert werden.

Behavior Driven Development wurde erstmals 2003 durch Dan North<ref name="Einführung">D.&nbsp;North, [http://dannorth.net/introducing-bdd Introducing Behaviour Driven Development]</ref> als Antwort auf [[testgetriebene Entwicklung]] beschrieben und hat sich seit damals weiterentwickelt.<ref>{{Internetquelle |autor=Dan North et al. |url=http://forums.pragprog.com/forums/95/topics/3035 |titel=Question about Chapter 11: Writing software that matters |sprache=en |offline=ja |archiv-url=https://web.archive.org/web/20091107220359/http://forums.pragprog.com/forums/95/topics/3035 |archiv-datum=2009-11-07 |archiv-bot= |abruf=2011-11-09 |zitat=The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space–&nbsp;around 2003-2004&nbsp;– this was a valid description. Now it only covers a small part of the BDD proposition.}}</ref> Dan North entwickelte auch das erste Framework für die Umsetzung von BDD, JBehave.<ref name="Einführung" />

== Techniken des Behavior Driven Developments ==
Behavior Driven Development besteht aus folgenden Elementen:
* Starke Einbeziehung der [[Stakeholder]] in den Prozess durch sogenannte Outside-In-Softwareentwicklung. Diese ist fokussiert auf die Erfüllung der Anforderungen der Auftraggeber, Enduser, Betrieb und Insider.
* Textuelle Beschreibung des Verhaltens der Software und von Softwareteilen durch Fallbeispiele. Verwendung genormter Schlüsselwörter zur Markierung von Vorbedingungen, externen Verhaltens und gewünschten Verhaltens der Software.
* Automatisierung dieser Fallbeispiele unter Verwendung von [[Mock-Objekt]]en zur Simulation von noch nicht implementierten Softwareteilen.
* Sukzessive Implementierung der Softwareteile und Ersetzung der Mock-Objekte.

Dadurch entsteht eine automatisiert prüfbare Beschreibung der umzusetzenden Software, welche jederzeit die Korrektheit der bereits umgesetzten Teile der Software überprüfen lässt.

Wichtig ist hierbei, dass die Beschreibung nicht die Implementierung der Anwendung vorgibt, sondern den Zweck der Anwendung in Form von Anwendungsbeispielen.

{{Zitat
 |Text=In addition to making it harder to focus on important issues, test scripts that describe ''how'' over-constrain the implementation. By specifying how something should be done, these tests don’t allow developers to find a better solution for the same problem. If specifications only cover what should be done then developers have more freedom to implement good solutions.
 |Sprache=en
 |Autor=Gojko Adzic
 |Quelle=Bridging the Communication Gap
 |Übersetzung=Zusätzlich dazu, dass es schwieriger ist, sich auf wichtige Fragen zu konzentrieren, überspezifizieren Testskripte, welche das ''wie'' beschreiben, die Implementierung. Durch das Beschreiben wie etwas gemacht werden sollte, erlauben diese Tests es Entwicklern nicht, bessere Lösungen für dasselbe Problem zu finden. Wenn Spezifikationen nur beschreiben ''was'' gemacht werden soll, dann haben Entwickler mehr Freiheit gute Lösungen zu implementieren.
 |ref=<ref>{{Literatur |Autor=Gojko Adzic |Titel=Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing |Verlag=Neuri Limited |Datum=2009 |ISBN=978-0-9556836-1-9 |Seiten=79-80 |Sprache=en |Umfang=284}}</ref>}}

== Beispiel in der Beschreibungssprache Gherkin ==
Beim Behavior Driven Development werden die Anforderungen an die Software mittels Beispielen, sogenannten Szenarien beschrieben. Üblicherweise wird für die Beschreibung dieser Szenarien ein bestimmtes Format vorgegeben, damit später die automatisierte Überprüfung der Szenarien einfach umzusetzen ist. Eines dieser Formate ist die Beschreibungssprache „Gherkin“.<ref>{{Internetquelle |url=https://github.com/cucumber/cucumber/wiki/Gherkin |titel=Cucumber - Gherkin |hrsg=Cucumber |sprache=en |abruf=2011-11-09}}</ref> Sie wird auch in verschiedenen Behavior-Driven-Development-Implementierungen verwendet. Diese Sprache gibt es sowohl mit englischen Schlüsselwörtern (Given, When, Then, And, …), deutschen (Gegeben, Wenn, Dann, Und, …) und in weiteren Sprachen.

Beispielsweise könnte die Anforderung „Rückgegebene und umgetauschte Ware kommt wieder ins Lager“ mit folgenden Szenarien beschrieben werden:

=== Szenario 1: Rückgegebene Ware kommt wieder ins Lager ===
* '''Gegeben''' ist, dass ein Kunde eine schwarze Hose gekauft hat
* '''Und''' wir daraufhin 3 schwarze Hosen im Lager hatten,
* '''Wenn''' er die Hose zurückgibt und dafür einen Gutschein erhält,
* '''Dann''' werden wir 4 schwarze Hosen im Lager haben.

=== Szenario 2: Umgetauschte Ware kommt wieder ins Lager ===
* '''Gegeben''' ist, dass ein Kunde einen blauen Rock gekauft hat
* '''Und''' wir daraufhin 2 blaue Röcke
* '''Und''' 3 schwarze Röcke im Lager hatten,
* '''Wenn''' er den blauen Rock gegen einen schwarzen Rock tauscht,
* '''Dann''' werden wir 3 blaue Röcke
* '''Und''' 2 schwarze Röcke auf Lager haben.

Jedes Szenario ist ein Beispiel, welches einen spezifischen Verhaltensaspekt der Applikation illustriert. Bei der Diskussion der Szenarien sollten sich die Teilnehmer fragen, ob die Ergebnisse der Szenarien immer in dem gegebenen Kontext auftreten. Damit können weitere Szenarien zur Klärung der Anforderung entstehen.<ref>{{Internetquelle |autor=Dan North |url=http://dannorth.net/whats-in-a-story |titel=What’s in a Story? |sprache=en |abruf=2011-11-09}}</ref> Beispielsweise könnte ein Fachwissender erkennen, dass zurückgegebene oder umgetauschte Ware nur dann ins Lager kommt, wenn sie nicht fehlerhaft ist. Die oben genannten Szenarien müssten dann entsprechend ergänzt werden.

Die Wörter Gegeben, Wenn und Dann werden verwendet, um die Szenarien deutlich zu machen, sie sind aber nicht unumgänglich.

== Umsetzung mit Mock-Objekten ==
Die definierten Szenarien können anschließend, noch vor Beginn der Implementierung, mit automatisierten Tests versehen werden. Diese testen die Software, während die noch nicht umgesetzten Teile mit Hilfe von Mock-Objekten simuliert werden. Diese Mock-Objekte können entweder händisch erstellt oder über ein [[Mocking Framework|Mocking-Framework]] wie beispielsweise [[Mockito]] oder [[EasyMock]] generiert werden. Die Mock-Objekte können nach Fertigstellung der entsprechenden Softwareteile ersetzt werden. Diese Mock-Objekte sind auch für die Entwicklung von [[Modultest|Unit-Tests]] während der Implementierung hilfreich. Diese Vorgangsweise unterstützt die Entstehung von kleinen und [[Lose Kopplung|lose gekoppelten]] Modulen und Klassen.

== Werkzeuge ==
Beim Einsatz von Behavior Driven Development benötigt man Werkzeuge („Frameworks“), für die man das Verhalten der in den Szenarien auftretenden Schritte programmiert, sodass das Werkzeug die Szenarien interpretieren und gegen die umgesetzte Applikation ausführen kann. Die Werkzeuge selbst sind oft nur für bestimmte Programmiersprachen geeignet. Die bekanntesten Vertreter sind [[JBehave]], [[Framework for Integrated Test|Framework for Integrated Test (FIT)]], [[FitNesse]], [[Concordion]] für Java und [[RBehave]], sowie [[Cucumber (Software)|Cucumber]] für [[Ruby (Programmiersprache)|Ruby]], Java und JavaScript.

'''C++'''
* Catch<ref name="Catch">{{Internetquelle |url=https://github.com/philsquared/Catch |titel=Catch |werk=github.com |sprache=en |abruf=2017-09-25}}</ref>

'''Ruby'''
* RBehave<ref name="rbehave">{{Internetquelle |autor=Dan North |url=http://dannorth.net/2007/06/introducing-rbehave |titel=Introducing rbehave |datum=2007-06-17 |sprache=en |offline=ja |archiv-url=https://web.archive.org/web/20070620230359/http://dannorth.net/2007/06/introducing-rbehave |archiv-datum=2007-06-20 |archiv-bot= |abruf=2011-11-09}}</ref>

'''Python'''
* Aloe<ref name="aloe">{{Internetquelle |url=https://aloe.readthedocs.io/ |titel=Aloe |titelerg=BDD testing via nose |sprache=en |abruf=2020-06-19}}</ref>
* Behave<ref name="behave">{{Internetquelle |url=https://behave.readthedocs.io/ |titel=Behave |titelerg=behaviour-driven development, Python style. |sprache=en |abruf=2020-06-19}}</ref>
* radish<ref name="radish">{{Internetquelle |url=http://radish-bdd.github.io/ |titel=radish |titelerg=behavior driven development for python |sprache=en |abruf=2013-01-21}}</ref>

'''.NET'''
* NBehave<ref name="NBehave">{{Internetquelle |url=https://github.com/nbehave/NBehave |titel=NBehave |werk=github.com |abruf=2018-09-23}}</ref>
* MSpec / Machine.Specifications<ref name="machine.specifications - resharper">{{Internetquelle |autor= |url=http://therightstuff.de/2010/03/03/MachineSpecifications-Templates-For-ReSharper.aspx |titel=Machine.Specifications Templates For ReSharper |werk= |hrsg= |datum= |sprache=en |archiv-url=https://web.archive.org/web/20130814152742/http://therightstuff.de/2010/03/03/MachineSpecifications-Templates-For-ReSharper.aspx |archiv-datum=2013-08-14 |offline=1 |abruf=2013-09-01}}</ref><ref name="machine.specifications - net">{{Internetquelle |url=https://github.com/machine/machine.specifications/ |titel=machine/machine.specifications |titelerg=Machine.Specifications is a Context/Specification framework geared towards removing language noise and simplifying tests |sprache=en |abruf=2013-09-01}}</ref>
* Specflow<ref name="specflow">{{Internetquelle |url=http://www.specflow.org/ |titel=SpecFlow. Binding Business Requirements to .NET Code |abruf=2018-09-23}}</ref> und Pickles<ref name="pickles">{{Internetquelle |url=http://www.picklesdoc.com/ |titel=Pickles. Living Documentation |abruf=2018-09-23}}</ref>
* Concordion.NET<ref name="concordion.net">{{Internetquelle |url=http://concordion.org/dotnet/ |titel=Concordion |abruf=2018-09-23}}</ref>
* FSpec<ref name="fspece">{{Internetquelle |url=https://github.com/PeteProgrammer/fspec |titel=Fspec |werk=github.com |abruf=2018-09-23}}</ref>
* NaturalSpec<ref name="naturalspec">{{Internetquelle |url=https://github.com/forki/NaturalSpec |titel=NaturalSpec |werk=github.com |abruf=2018-09-23}}</ref>
* TickSpec<ref name="tickspec">{{Internetquelle |url=https://github.com/neoeinstein/TickSpec |titel=TickSpec |werk=github.com |abruf=2018-09-23}}</ref>
* SubSpec<ref name="subspec">{{Internetquelle |autor=Johannes Rudolph |url=https://bitbucket.org/johannesrudolph/subspec/wiki/Home |titel=SubSpec Wiki |werk=bitbucket.org |abruf=2018-09-23}}</ref>

'''Java'''
* JBehave<ref name="jbehave">{{Internetquelle |url=http://jbehave.org/ |titel=JBehave |sprache=en |abruf=2018-09-23}}</ref>
* Jnario<ref>{{Internetquelle |url=http://jnario.org/ |titel=Jnario Homepage |sprache=en |abruf=2013-01-30}}</ref>
* JGiven<ref>{{Internetquelle |url=https://entwickler.de/java/lessons-learned |autor=Marco Schulz  |titel=Behavior-driven Development: Akzeptanztests in Java mit JGiven |werk=Java Magazin 2.2020 |datum=2019-11-29 |sprache=de-DE |abruf=2023-12-08}}</ref>

'''JavaScript / TypeScript'''
* Jasmine<ref name="Jasmine">{{Internetquelle |url=https://jasmine.github.io/ |titel=Jasmine - Behavior-Driven JavaScript |sprache=en |abruf=2018-12-06}}</ref>
* Mocha<ref name="mocha">{{Internetquelle |url=https://mochajs.org/ |titel=Mocha |sprache=en |abruf=2018-11-02}}</ref> in Kombination mit Chai<ref name="chai">{{Internetquelle |url=https://www.chaijs.com/ |titel=Chai |sprache=en |abruf=2018-11-02}}</ref> und Sinon.js<ref name="sinonjs">{{Internetquelle |url=https://sinonjs.org/ |titel=Sinon |sprache=en |abruf=2018-11-02}}</ref>

'''Scala'''
* ScalaTest<ref name="scalatest">{{Internetquelle |url=http://scalatest.org/ |titel=ScalaTest |sprache=en |abruf=2018-11-26}}</ref>

'''PHP'''
* Behat<ref name="behat">{{Internetquelle |url=http://behat.org/ |titel=Behat |titelerg=Behat – BDD for PHP |sprache=en |abruf=2012-11-07}}</ref>
* Codeception<ref name="codeception">{{Internetquelle |url=https://codeception.com/ |titel=Codeception |abruf=2018-09-23}}</ref>

'''Go'''
* Ginkgo<ref name="ginkgo">{{Internetquelle |url=http://onsi.github.io/ginkgo/ |titel=Ginkgo. A Golang BDD Testing Framework |abruf=2018-09-23}}</ref>

'''iOS'''

* Kiwi<ref>{{Internetquelle |url=https://github.com/kiwi-bdd/Kiwi/wiki |titel=Kiwi |sprache=en |abruf=2016-05-20}}</ref>

'''Plattformübergreifend'''
* [[Cucumber (Software)|Cucumber]]
* Squish<ref>{{Internetquelle |url=https://www.froglogic.com/squish/features/bdd-behavior-driven-development-testing/ |titel=Squish – GUI Testing with BDD integration |sprache=en |abruf=2017-01-20}}</ref>
* Yulup<ref>{{Internetquelle |url=https://www.yulup.com/de/dokumentation/quick_start_guide.html#section-1-091 |titel=Yulup – Agile Requirements Engineering using the BDD approach |sprache=en |abruf=2017-08-07}}</ref>

== Verwandte Ansätze ==
Im Zusammenhang mit dem Einsatz [[Generatives KI-Modell|generativer KI-Modelle]] in der [[Softwaretechnik|Softwareentwicklung]] wird ebenfalls der Begriff ''Spec-Driven Development'' verwendet. Darunter werden Vorgehensweisen verstanden, bei denen vor der Implementierung strukturierte [[Spezifikation|Spezifikationen]] erstellt werden, die als gemeinsame Grundlage für menschliche Entwickler und automatisierte [[KI-Agent|Coding-Agenten]] dienen. Die Spezifikation beschreibt dabei das beabsichtigte Verhalten der Software, wird teilweise unter Nutzung [[Large Language Model|großer Sprachmodelle]] erarbeitet und dient als zentraler Bezugspunkt für die weitere Umsetzung.<ref>{{Internetquelle |autor=Birgitta Böckeler |url=https://martinfowler.com/articles/exploring-gen-ai.html/sdd-3-tools.html |titel=Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl |werk=martinfowler.com |datum=2025-10-15 |sprache=en |abruf=2026-02-08}}</ref><ref>{{Internetquelle |autor=Madeleine Domogalla |url=https://www.heise.de/news/software-architektur-tv-Spec-Driven-Development-mit-Simon-Martinelli-11138731.html |titel=software-architektur.tv: Spec-Driven Development mit Simon Martinelli |werk=heise.de |hrsg=Heise Medien GmbH & Co. KG |datum=2026-01-15 |sprache=de |abruf=2026-02-08}}</ref>

== Literatur ==
* {{Literatur
   |Autor=David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North
   |Titel=The RSpec Book. Behaviour-Driven Development with RSpec, Cucumber, and Friends
   |Verlag=Pragmatic
   |Ort=Lewisville TX
   |Datum=2010
   |ISBN=978-1-934356-37-1
   |Sprache=en
   |Online=[http://www.pragprog.com/titles/achbd/the-rspec-book online]
   |Abruf=2011-11-12}}
* {{Literatur
   |Autor=Aslak Hellesoy, Matt Wynne
   |Titel=The Cucumber Book. Behaviour-Driven Development for Testers and Developers
   |Reihe=Pragmatic Programmers
   |Verlag=Pragmatic Bookshelf
   |Ort=Dallas TX u.&nbsp;a.
   |Datum=2012
   |ISBN=978-1-934356-80-7
   |Sprache=en}}
* {{Literatur
   |Autor=Gojko Adzic
   |Titel=Specification by Example
   |Verlag=Manning
   |Ort=Shelter Island, New York
   |Datum=2011
   |ISBN=978-1-617290084
   |Sprache=en}}

== Weblinks ==
* {{Internetquelle
   |autor=Dan North
   |url=http://dannorth.net/introducing-bdd
   |titel=Introducing BDD
   |hrsg=Better Software Magazin
   |datum=2006-03
   |sprache=en
   |abruf=2011-11-12}}
* {{Internetquelle
   |autor=Gregory Brown
   |url=http://www.oreillynet.com/pub/a/ruby/2007/08/09/behavior-driven-development-using-ruby-part-1.html
   |titel=Behavior Driven Development Using Ruby (Part 1)
   |hrsg=O’Reilly
   |datum=2007-08-09
   |sprache=en
   |abruf=2011-11-12}}
* {{Internetquelle
   |autor=Gregory Brown
   |url=http://www.oreillynet.com/pub/a/ruby/2007/08/30/behavior-driven-development-using-ruby-part-2.html
   |titel=Behavior Driven Development Using Ruby (Part 2)
   |hrsg=O’Reilly
   |datum=2007-08-30
   |sprache=en
   |abruf=2011-11-12}}
* {{Internetquelle
   |autor=Andrew Glover
   |url=http://www.ibm.com/developerworks/java/library/j-cq09187/index.html
   |titel=In pursuit of code quality: Adventures in behavior-driven development
   |titelerg=Isn’t it time you learned how to JBehave?
   |hrsg=IBM Developer Works
   |datum=2007-09-18
   |sprache=en
   |abruf=2011-11-12}}
* {{Internetquelle
   |autor=Pramodkumar J Sadalage
   |url=http://www.methodsandtools.com/archive/archive.php?id=78
   |titel=Behavior Driven Database Development (BDDD)
   |hrsg=Methods and Tools
   |sprache=en
   |abruf=2011-11-12}}
* {{Internetquelle
   |autor=Scott Bellware
   |url=http://www.tvagile.com/2009/08/13/good-test-better-code-from-unit-testing-to-behavior-driven-development/
   |titel=Good Test, Better Code
   |titelerg=From Unit Testing to Behavior-Driven Development
   |hrsg=Agile Scrum Videos and Tutorials
   |datum=2009-08-13
   |sprache=en
   |abruf=2011-11-12}}
* {{Internetquelle
   |url=http://tekpub.com/view/concepts/5
   |titel=Behavior Driven Design with Specflow
   |hrsg=[[Tekpub]]
   |abruf=2013-01-30}}
* [http://bdd.tips/ bdd.tips] – Tutorial zur Umsetzung von BDD GUI Tests, abgerufen am 19. Januar 2017.

== Einzelnachweise ==
<references responsive />

[[Kategorie:Testen (Software)]]
[[Kategorie:Softwaretechnik]]
[[Kategorie:Vorgehensmodell (Software)]]