Behavior driven development

Behavior driven development
See also
Descriptive model Decision tree Feature-driven development MoSCoW technique Level of complexity Depth interview Activity chart Descriptive study Decision point

Behavior Driven Development (BDD) - a kind of agile approach to software development developed by North Dana, based on the Test Driven Development process (TDD) In this method, acceptance tests are written in natural language, the aim being a common understanding between individual members of the project team. Mapping of sentences written this way is the beginning of the project cycle. Based on TDD practices, one should start with an unsuccessful acceptance test carried out by the client, describing the behavior of the system from his point of view. In BDD, they are described as examples understandable for each team member. The description process is used to obtain feedback from stakeholders in order to verify the chosen course of action before they are taken. The aim is to create a "ubiquitous" language used to exchange information about the system, including its description.

Geneza Behavior Driven Development

TDD is an evolutionary approach based on short development cycles and agile methodologies in writing automated tests preceding both the creation of the correct code, as well as its reconstruction and continuous integration. The TDD type is Acceptance Test Driven Development (ATDD). In this variant, the software development process is based on acceptance tests containing the requirements of stakeholders. It helps developers translate these requirements into so-called "Test cases" and verification of system functionality. The requirement is satisfied if all related tests or criteria are met. Both TDD and ATDD pose some problems. Among them, the most important is the fact that they are focused more on verifying the current state of the system than on its desired behavior. In both approaches, there is also a natural language that does not have a strict structure. It is used to describe "cases", and because of this disorder, it causes difficulties in understanding them.

BDD is essentially an evolution of both approaches. This method focuses primarily on developing a precise description of the behavior of the target system, so that they can be automated. The tests in BDD are written in a clear and easy to understand way due to the use of a "common" language, which is a stakeholder tool, used to accurately describe tests.

Features of Behavior Driven Development

1. "Ubiquitous" language This concept is central to BDD, it is a language whose structure is derived from a predetermined model. It contains all the concepts that will be used to define the system behavior. This language is based on a business model. It enables seamless communication between clients and developers. The creation of this kind of language is particularly important due to the fact that it should be used throughout the software development cycle. A set of concepts or a dictionary is created at the very beginning of the project. Most vocabulary should be prepared in the analysis phase, however, they can be extended in all phases of development. All specialists and developers for whom it will later become a tool should be involved in the process.

2. Interactive process decomposition

The problem of developers and clients' agreement is common. The software development project must provide some business value that is difficult to express. For this reason, analysis in BDD begins with the identification of more strict and precise in the description of the expected behavior of the system. They are derived from the business value to be delivered. As a result of further analysis, the so-called "Feature sets". These collections are shown in "user stories" describing the interaction between the user and the system. They must provide answers to three questions:

• What is the user's role in a given story?
• Which system's functionality does the user want?
• What is the benefit of the user if the system provides the functionality?

3. A simple description of the text using user history templates

BDD does not allow arbitrage in formatting the description of features / functionality, user histories and scenarios. There are specific templates prepared based on a previously created language. Usually they look like:

[Title of History] (one sentence describing the story) As [Role] I want [Functionality] Thanks to which I will get [Benefit]

The scenario describes how a system containing a given functionality should behave in a specific state or in the case of a specific event. Scenarios consist of contexts, events and actions. The template for scenarios looks like the following:

Scenario 1: [Scenario Title] Dany / dana / dane [Status / Situation (context)] And [Wider Context] ... When [Event] Then [Effect] And [More Effects] ... Scenario 2 [Scenario Title] ...

4. Automated acceptance tests along with mapping rules

The characteristics of automated acceptance tests in BDD are taken from ATDD. The test itself consists in determining the system's behavior, enabling verification of the interaction rather than the behavior of individual objects rather than their states. Developers start from pre-prepared scenarios. They are translated into tests, a factor determining implementation. They should be read automatically, which means that acceptance criteria also have to be imported and analyzed automatically. Mapping rules provide standards for mapping scenarios and translating them into test code. One of the approaches to the above is the following set of steps:

• user's history is prepared as a file containing a set of scenarios
• the file name is mapped to the specified user history class
• each scenario step is mapped to a test method, localized using a footnote describing the step

5. Readable, behavior-oriented specification code

According to the BDD assumptions, the code should be part of the system documentation. This approach corresponds to the values of agile methodologies. The code must be readable and the specification must be part of it.

6. 'Behavior Driven' in individual phases

• in the initiation / planning phase: behaviors must correspond to the business value provided
• in the analysis phase: the components of a given value are divided into features / functionalities
• in the implementation phase: automated acceptance testing is an integral part of it

References

• Solis, C., & Wang, X. (2011, August). A study of the characteristics of behaviour driven development. In 2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications (pp. 383-387). IEEE.
• Soeken, M., Wille, R., & Drechsler, R. (2012, May). Assisted behavior driven development using natural language processing. In International Conference on Modelling Techniques and Tools for Computer Performance Evaluation (pp. 269-287). Springer, Berlin, Heidelberg.
• Rahman, M., & Gao, J. (2015, March). A reusable automated acceptance testing architecture for microservices in behavior-driven development. In 2015 IEEE Symposium on Service-Oriented System Engineering (pp. 321-325). IEEE.