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, [http://dannorth.net/introducing-bdd Introducing Behaviour Driven Development] ] as a response to Test Driven Development, and has evolved over the last few years.
The focus of BDD is the language and interactions used in the process of software development. Behavior-driven developers use their native language in combination with the ubiquitous language of Domain Driven Design to describe the purpose and benefit of their code. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management etc.
BDD Practices
The practices of BDD include: * Driving development from the outside-in * Using examples to describe the behavior of the application, or of units of code * Automating those examples to provide quick feedback and regression testing * Using 'should' to help drive out responsibility and allow the behavior to be questioned * Using 'ensure' to differentiate between outcomes which are the responsibility of the code in question, and those caused by other elements of code as a side-effect * Using mocks to stand-in for modules of code which have not yet been written
Outside-In
BDD is driven by Business Value; that is, the benefit to the business which accrues once the application is in production. The only way in which this benefit can be realized is through the User Interface(s) to the application, usually (but not always) a GUI.
In the same way, each piece of code, starting with the UI, can be considered a stakeholder of the other modules of code which it uses. Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.
The first piece of production code that BDD developers implement is the UI. Developers can then benefit from quick feedback as to whether the UI looks and behaves appropriately. Through code, and using principles of good design and refactoring, developers discover collaborators of the UI, and of every unit of code thereafter. This helps them adhere to the principle of YAGNI, since each piece of production code is required either by the business, or by another piece of code already written.
cenarios, or Application Examples
The requirements of a retail application might be, "Refunded or replaced items should be returned to stock."
In BDD, a developer or QA might clarify the requirements by breaking this down into specific examples, eg.
cenario 1: Refunded items should be returned to stock
* Given a customer buys a black jumper * and I have three black jumpers left in stock * when he returns the jumper for a refund * then I should have four black jumpers in stock
Scenario 2: Replaced items should be returned to stock
* Given that a customer buys a blue garment * and I have two blue garments in stock * and three black garments in stock. * When he returns the garment for a replacement in black, * Then I should have three blue garments in stock * and two black garments in stock
Each scenario is an exemplar, designed to illustrate a specific aspect of behavior of the application.
When discussing the scenarios, participants question whether the outcomes described always result from those events occurring in the given context. This can help to uncover further scenarios which clarify the requirements. For instance, a domain expert noticing that refunded items are not always returned to stock might reword the requirements as "Refunded or replaced items should be returned to stock unless faulty."
This in turn helps participants to pin down the scope of requirements, which leads to better estimates of how long those requirements will take to implement.
The words Given, When and Then are often used to help drive out the scenarios, but are not mandated.
These scenarios can also be automated, if an appropriate tool exists to allow automation at the UI level. If no such tool exists then it may be possible to automate at the next level in, ie: if an MVC design pattern has been used, the level of the Controller.
Unit-level Examples and Behavior
The same principles of examples, using contexts, events and outcomes can be used to drive development at a unit level. For instance, the following examples describe an aspect of behavior of a list:
Example 1: New lists are empty * Given a new list * Then the list should be empty.
Example 2: Lists with things in them are not empty. * Given a new list * When we add an object * Then the list should not be empty.
Both these examples are required to describe the behavior of the list.isEmpty() method, and to derive the benefit of the method. These examples can be automated using TDD frameworks. In BDD these examples are usually encapsulated in a single test method, with the name of the method being a complete description of the behavior.
For instance, using Java and JUnit 4, the above examples might become:
public class ListTest {
@Test public void shouldKnowWhetherItIsEmpty() { List list1 = new List(); assertTrue(list1.isEmpty());
List list2 = new List(); list2.add(new Object()); assertFalse(list2.isEmpty());
Sometimes the difference between the context, events and outcomes may be made more explicit. For instance:
public class WindowControlBehavior {
@Test public void shouldCloseWindows() { // Given WindowControl control = new WindowControl("My AFrame"); AFrame frame = new AFrame(); // When control.closeWindow(); // Then ensureThat(!frame.isShowing());
However the example is phrased, the effect should be that of describing the behavior of the code in question. For instance, from the examples above one can derive:
* List should know when it is empty * WindowControl should close windows
The description is useful if the test fails, and provides documentation of the code's behavior to anyone interested in Lists or WindowControls. Once the examples have been written they are then run and the code implemented to make them work in the same way as TDD.
Using Mocks
Because of the outside-in nature of BDD, developers will often find themselves trying to use units of code which don't yet exist. When this happens, an object which is simpler than the desired code, and provides the same interface but predictable behaviour, can be injected into the code which needs it.
These objects can either be created by hand, or created using a mocking framework such as JMock or EasyMock.
BDD proponents claim that the use of "should" and "ensureThat" in BDD examples encourages developers to question whether the responsibilities they're assigning to their classes are appropriate, or whether they can be delegated or moved to another class entirely. Questioning responsibilities in this way, and using mocks to fulfill the required roles of collaborating classes, encourages the use of Role-based Interfaces. It also helps to keep the classes small and loosely coupled.
References
External links
* [http://dannorth.net/introducing-bdd Dan North's article introducing BDD] * [http://behavior-driven.org/ Introduction to Behavior Driven Development] * [http://www.concordion.org Concordion: a Java automated testing tool for BDD that uses plain English to describe behaviors] * [http://www.oreillynet.com/pub/a/ruby/2007/08/09/behavior-driven-development-using-ruby-part-1.html Behavior Driven Development Using Ruby (Part 1)] * [http://www.oreillynet.com/pub/a/ruby/2007/08/30/behavior-driven-development-using-ruby-part-2.html Behavior-Driven Development Using Ruby (Part 2)] * [http://www.ibm.com/developerworks/java/library/j-cq09187/index.html In pursuit of code quality: Adventures in behavior-driven development by Andrew Glover] * [http://www.narisa.com/forums/index.php?showtopic=22293 Discussion of an approach to support a non-English language for BDD] (in Thai)
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… … Deutsch 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
