Behavior Driven Development

Behavior Driven Development

Behavior Driven Development (BDD) (deutsch Verhaltensgetriebene Softwareentwicklung) ist eine Technik der 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 derart textuell festgehalten, dass diese später automatisiert auf ihre korrekte Implementierung getestet werden können. Die Anforderungen werden dabei meist in "wenn" - "dann" Sätzen basierend auf der ubiquitäten Sprache des Domain-Driven Designs 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[1] als Antwort auf Testgetriebene Entwicklung beschrieben und hat sich seit damals weiterentwickelt.[2] Dan North entwickelte auch das erste Framework für die Umsetzung von BDD, JBehave[1], weitere Frameworks sind RBehave[3] oder Cucumber[4].

Inhaltsverzeichnis

Techniken des Behavior Driven Developments

Behavior Driven Development besteht aus folgenden Elementen:

  • Starke Einbeziehung von 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-Objekten 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.

Beispiel in der Beschreibungssprache Gherkin

Beim Behavior Driven Development werden die Anforderungen an die Software mittels Beispielen, sogenannten Szenarios beschrieben. Üblicherweise wird für die Beschreibung dieser Szenarios ein bestimmtes Format vorgegeben, damit später die automatisierte Überprüfung der Szenarien einfach umzusetzen ist. Eines dieser Formate ist die Beschreibungssprache "Gherkin".[5] Sie wird auch in verschiedenen Behavior Driven Development Implementierungen verwendet. Diese Sprache gibt es sowohl mit englischen Schlüsselworten (Given, When, Then, And, ...), deutschen (Gegeben, Wenn, Dann, Und, ...) und weiteren Sprachen.

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

Szenario 1: Rückgegebene Ware kommt wieder ins Lager

  • Gegeben ist, dass ein Kunde eine schwarze Hose gekauft hat
  • und wir haben 3 schwarze Hosen im Lager,
  • wenn er die Hose zurückgibt und dafür einen Gutschein erhält,
  • dann sollten 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 haben 2 blaue Röcke
  • und 3 schwarze Röcke im Lager,
  • wenn er den blauen Rock gegen einen schwarzen Rock tauscht,
  • dann sollten 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.[6] 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 - noch nicht umgesetzte Teile werden mit Hilfe von Mock Objekten simuliert. Diese Mock Objekte können entweder händisch erstellt, oder über ein Mocking Framework wie Mockito, Moq, NMock, Rhino Mocks, JMock oder EasyMock generiert werden. Nach Fertigstellung der entsprechenden Softwareteile, können die sie repräsentierenden Mock Objekte ausgetauscht werden. Diese Mock Objekte sind auch für die Entwicklung von Unit-Tests während der Implementierung hilfreich. Diese Vorgangsweise unterstützt die Entstehung von kleinen und lose gekoppelten Modulen und Klassen.

Werkzeuge

Beim Einsatz von Behavior Driven Development benötigt man Werkzeuge mit deren Hilfe man das Verhalten derart beschreibt, dass das Werkzeug dieses gegen die umgesetzte Applikation testen kann. Die Werkzeuge selbst sind oft nur für bestimmte Programmiersprachen geeignet. Die bekanntesten Vertreter sind JBehave sowie Framework for Integrated Test (FIT) und FitNesse für Java und RBehave und Cucumber für Ruby.

Literatur

  • David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North: The RSpec Book. Behaviour-Driven Development with RSpec, Cucumber, and Friends. The Pragmatic Bookshelf Pragmatic Programmers, 22. Dezember 2010, ISBN 978-1-93435-637-1 (http://www.pragprog.com/titles/achbd/the-rspec-book, abgerufen am 12. November 2011).
  • Aslak Hellesoy, Matt Wynne: The Cucumber Book. Behaviour-Driven Development for Testers and Developers. The Pragmatic Bookshelf Pragmatic Programmers, 10. Dezember 2011, ISBN 978-1934356807.

Weblinks

Einzelnachweise

  1. a b D.North, Introducing Behaviour Driven Development
  2. Dan North et. al.: Question about Chapter 11: Writing software that matters. abgerufen am 9. November 2011 (englisch): „The prhase "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 – around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition.“
  3. Dan North: Introducing rbehave. 17. Juni 2007, abgerufen am 9. November 2011 (englisch).
  4. Cucumber. behavior driven development with elegance and joy. Abgerufen am 9. November 2011 (englisch).
  5. Cucumber - Gherkin. Cucumber, abgerufen am 9. November 2011 (englisch).
  6. Dan North: What’s in a Story? Abgerufen am 9. November 2011 (englisch).

Wikimedia Foundation.

Игры ⚽ Нужна курсовая?

Schlagen Sie auch in anderen Wörterbüchern nach:

  • Behavior Driven Development — (or BDD) is an Agile software development technique that encourages collaboration between developers, QA and non technical or business participants in a software project. It was originally conceived in 2003 by Dan North D.North,… …   Wikipedia

  • Behavior driven development — (ou BDD) est une méthode Agile qui encourage la collaboration entre les développeurs, les responsables qualités, les intervenants non techniques et les entreprises participants à un projet de logiciel. Il a été conçu en 2003 par Dan North comme… …   Wikipédia en Français

  • Behavior Driven Development — (ou BDD) est une méthode Agile qui encourage la collaboration entre les développeurs, les responsables qualités, les intervenants non techniques et les entreprises participants à un projet de logiciel. Il a été conçu en 2003 par Dan North comme… …   Wikipédia en Français

  • Test-driven development — (TDD ) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and… …   Wikipedia

  • Test Driven Development — Le Test Driven Development (TDD) ou en Français développement piloté par les tests est une méthode de développement de logiciel qui préconise d écrire les tests unitaires avant d écrire le code source d un logiciel. Sommaire 1 Le cycle de TDD 2… …   Wikipédia en Français

  • Behavior change (public health) — Behavior change has become a central objective of public health interventions over the last half decade, as the influence of prevention within the health services has increased. The increased influence of prevention has coincided with increased… …   Wikipedia

  • List of software development philosophies — This is an incomplete list of approaches, styles, and philosophies in software development.* Agile software development * Agile Unified Process (AUP) * Behavior Driven Development (BDD) * Big Design Up Front (BDUF) * Brooks s law * Cathedral and… …   Wikipedia

  • Development communication — Development Communication, has been alternatively defined as a type of marketing and public opinion research that is used specifically to develop effective communication or as the use of communication to promote social development. Defined as the …   Wikipedia

  • Dynamic Systems Development Method — (DSDM) is a software development approach originally based upon the Rapid Application Development (RAD) methodology. DSDM is an iterative and incremental approach that emphasizes continuous user involvement. Its goal is to deliver software… …   Wikipedia

  • Lawrence Kohlberg's stages of moral development — constitute an adaptation of a psychological theory originally conceived of by the Swiss psychologist Jean Piaget. Kohlberg began work on this topic while a psychology postgraduate student at the University of Chicago,[1] and expanded and… …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”