Behavior Driven Development
Behavior Driven Development ( BDD) ( behavior -driven software development ) is a technique of agile software development which strengthens the cooperation between quality management and business analysis in software development projects. When Behavior Driven Development the objects, aims and results of the software are such textually stated that they can be tested automatically later on their correct implementation during the requirements analysis. The requirements are usually in the " if-then " written there - sets based on the ubiquitous language of domain driven design. This way the transition between the language of definition of the business requirements and the programming language, by which the requirements are implemented, be facilitated.
Behavior Driven Development was first described as a response to Test Driven Development in 2003 by Dan North and has evolved since then. Dan North also developed the first framework for the implementation of BDD, JBehave, other frameworks are RBehave, NBehave, MSpec / Machine.Specifications, Cucumber, radish, Specflow, Behat, subspec or Jnario.
Techniques of Behavior Driven Developments
Behavior Driven Development consists of the following elements:
- A strong involvement of stakeholders in the process through so-called outside-in software development. This is focused on meeting the requirements of the customer, end users, operation and insiders.
- Textual description of the behavior of software and software components through case studies. Use of standardized keywords for labeling of preconditions external behavior and desired behavior of the software.
- Automation of these case studies, using mock- objects to simulate not implemented software components.
- Gradual implementation of the software components and replacement of mock objects.
This creates an automated verifiable description of the software to be implemented, which can be checked at any time the correctness of the already implemented parts of the software.
Example, in the description language Gherkin
When Behavior Driven Development describes the requirements on the software by way of example, so-called scenarios. Usually, a specific format is prescribed for the description of these scenarios, so that the automated checking of the scenarios is easy to implement later. One of these formats is the description language " Gherkin". It is also used in various implementations Behavior Driven Development. This language gives it both with English key words ( Given, When, Then, And, ... ), German (Given, When, Then, And, ...) and other languages.
For example, the request " return given and vice exchanged goods come into the camp again " are described with the following scenarios:
Scenario 1: Restoring Shared goods come into the camp again
- Is given that a customer has bought a black pants
- And we have 3 black trousers in the camp,
- If he returns the pants and receives a voucher,
- Then we should have 4 black pants in stock.
- Is given that a customer has purchased a blue skirt
- And we have 2 blue skirts
- And three black skirts in the camp,
- Then we should be 3 blue skirts
- And have 2 black skirts in stock.
Each scenario is an example that illustrates a specific aspect of the application behavior. In discussing the scenarios, the participants should ask whether the results of the scenarios always occur in the given context. This may entail additional scenarios to clarify the request. For example, a skilled knower could recognize that returned or replaced goods only comes into stock, if it is not defective. The above scenarios would have to be amended accordingly.
The words Given, When and Then use the scenarios to make it clear, but they are not inevitable.
Reaction with mock objects
The scenarios can then be defined, before the start of the implementation are provided with automated tests. This test the software, while the unreacted components are simulated with the help of mock objects. These mock objects can be created either manually or generated via a Mocking framework such as Mockito or EasyMock. Mock objects can be replaced after completion of the corresponding software components. These mock objects are also helpful for the development of unit tests during the implementation. This approach supports the development of small and loosely coupled modules and classes.
Tools
When using Behavior Driven Development you need tools with which one describes the behavior so that the tool can test this against the converted application. The tools themselves are often only suitable for certain programming languages. The best known representatives are JBehave, Framework for Integrated Test (FIT), FitNesse for Java and RBehave and Cucumber for Ruby, Java and Java Script.