Behavior Driven Development

Behavior-driven development (BDD) is an approach in agile software development that emerged from test-driven development (TDD) and is based on an object-oriented approach and domain-driven design (DDD). BDD is used mainly in complex software projects and simplifies the use of tools that are used to test the functionalities and the design of the software and its interfaces. BDD is used in the creation of online shops, for example, but is not bound to a single framework or programming language. For example, BDD tools exist for Java, JavaScript, Ruby, PHP, Python, or the .NET environment. The goal of behavior-driven software development is to simplify the collaboration between developers and management through a ubiquitous language, thereby automating the migration of the product into different environments and testing.

General information

The central differences between TDD and BDD is evident in the approach to modeling software and web applications. While TDD defines test cases before the software is created to automatically test the functionalities later, behavior-driven development outlines the desired behavior of the software from the point of view of a user, similar to the user stories in extreme programming. These requirements are formulated in a language that facilitates the integration of tasks, objectives, and results of a software in different frameworks and systems, and guides the methodology of software design.

The language is intended to simplify the implementation of the desired behavior of a software by means of certain programming languages ​​so that all involved developers as well as the management can collaborate. Since the definition of test cases can be complex in the case of the test-driven development and difficult for lay persons, the language and the domain-oriented approach with BDD functions as a link between the teams involved and the infrastructure used. At the center of BDD are the vocabulary, framework, methodology, and the objective which the software is to achieve with regard to the user stories.

How it works

BDD is characterized by two main features:

• Behavior: Software development is based on the behavior the product is supposed to show. However, a test case is only available to the developer. It defines the technical requirements of a software in such a way that technically trained personnel can understand it. But contractors, sponsors, and users of the software, will only be partially able to think with it. Focusing on the behavior of the software, harmonizes the problems of technically demanding implementation of test cases, product requirements, and migration to other systems (development, test, and production environment). Test cases, requirements, and domain-specific problems are generally considered to be the behavior of the software. Instead of defining test methods, the behavior of the software is described, so that all participants can immediately understand the meaning and purpose of individual test cases and user stories. The focus on the behavior of the software also benefits the business value, which a software has for a company or a group of clients. If the software or web application does exactly what it is supposed to, the business objectives are at least partially achieved. Moreover, the BDD approach facilitates the creation of documentation, specifications and APIs.
• Language: The focus on behavior leads directly to the content features of the BDD. A developer knows what the software is supposed to do and keeps it in requirement catalogs. However, the developer has privileged access to it, while other project participants such as project management and quality assurance do not. The language used with BDD remedies this. A technical documentation of test cases is translated directly into natural-language elements, so it is also clear which requirements the software must meet, depending on the complex professional contexts of the domain on which the product is created. Thanks to the ubiquitous language, the work on the software can be understood to the last detail by all project participants and the architecture of the software (mostly layer architecture) is directly related to the domain for which the software is created. The domain-driven design is independent of certain programming paradigms, tools, and frameworks, but is usually used in the context of object-oriented programming.

Examples

A typical example of the behavior-driven design is the formulation of a natural-language scenario, which is directly oriented to the logic of the software. Scenarios are determined using standard logical expressions such as if, then, and, or as well as any given conditions. Each scenario represents an abstract user story that is made possible by the application, such as a login, purchase of a product in an online shop, or the data management of ordered products. The special feature of BDD is the fact that these stories are translated directly into executable tests via ubiquitous language.

An example of a login process on a website:

• Given: An existing account with customer data such as username, email address, and password
• The customer logs into his account with his/her access data. If he enters his/her user name and password on the login website, his/her registration should be recognized and confirmed. If successful, a confirmation page is displayed.
• If the entries are not correct, an error message should be displayed and show what has been entered incorrectly.
• Various eventualities such as a disconnection at server or user side should be linked to disjunctive conditions. If the communication between the server or the client fails, an error message should be displayed.

Depending on the BDD tools and frameworks used, these linguistic sentences are translated into executable code. For this purpose, they are usually arranged in rows from 1 to X and use the vocabulary, which allows the transition of the user story to the technical logic of the program. At the same time, the test cases are adequately specified with the vocabulary, which considerably simplifies the subsequent automated testing of the functionalities of the applications.

Some examples of BDD tools:

• Gherkin
• JBehave
• Cucumber
• Behat

Relevance for programming

Dan North designed behavior-driven software development in response to the complexity of test-driven design. On the one hand, by self-motivation, as he dealt more closely with this important topic within agile methods. On the other hand, he wanted to facilitate access to the advantages of the test-first approach for beginners of agile methods. Against the backdrop of different development environments, TDD led to misunderstandings and conflicts if the testing was not carried out extensively and correctly. The ubiquitous language used with BDD and the focus on user behavior and thus the application is supposed to minimize these misunderstandings and difficulties.

At the same time, project management, quality assurance, and the engineers who set up the infrastructure for development receive important assistance to be able to make the right decisions. Similar to other agile approaches, the workflows, which require a smooth cooperation of the project participants, are at the center of the design. The behavior of the application directs the design process methodically. The ubiquitous language translates this behavior into elements that anticipate an analysis of the code as well as subsequent acceptance tests before the software is finished. The automation of testing can also lead to lower overall costs.

Web Links

• BDD Definition
• Infos about BDD]
• The beginner’s guide to BDD
• How Test-Driven Development Works (And More!)
• What is the difference between Test Driven Development (TDD) and Behavior Driven Development (BDD)?