Behavior driven development

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

Examples of Behavior driven development

• A team of developers are assigned a project to build an e-commerce website. Using BDD, they would begin by writing down a list of acceptance tests in natural language, such as "the customer should be able to add items to their cart" and "the customer should be able to check out their items". This process allows the team to obtain feedback from stakeholders in order to verify the chosen course of action before they are taken.
• A team of developers are assigned a project to build an online video streaming service. Using BDD, they would begin by writing down a list of acceptance tests in natural language, such as "the user should be able to sign up for an account" and "the user should be able to stream videos from the service". This process allows the team to obtain feedback from stakeholders in order to verify the chosen course of action before they are taken.
• A team of developers are assigned a project to build a mobile application. Using BDD, they would begin by writing down a list of acceptance tests in natural language, such as "the user should be able to log in using their credentials" and "the user should be able to search for content in the application". This process allows the team to obtain feedback from stakeholders in order to verify the chosen course of action before they are taken.

Advantages of Behavior driven development

Behavior Driven Development (BDD) is an agile approach to software development that focuses on creating a common understanding between members of the project team. The following are some of the advantages of using BDD:

• It encourages collaboration between team members by providing a common language for communication.
• It allows for quick feedback and adaptation to stakeholder requirements as the project progresses.
• It makes it easier to identify problems early on in the development cycle, resulting in fewer costly changes down the line.
• It enables teams to create effective user stories that describe the behavior of the system from the user's point of view.
• It helps to ensure that the final product is of high quality and meets the customer's expectations.

Limitations of Behavior driven development

• Behavior Driven Development (BDD) is an agile approach to software development that emphasizes collaboration between team members and stakeholders. However, it has some drawbacks, including the following:
• BDD is often difficult to implement in large-scale projects due to the need for comprehensive collaboration and communication between stakeholders.
• BDD is not a silver bullet; issues such as design and architecture decisions can still arise, and the process can be time-consuming.
• BDD can be challenging to learn and understand, and team members may need additional training to use it successfully.
• Writing test cases in "ubiquitous" language can be time-consuming and may require significant effort to ensure that everyone understands the tests.
• BDD does not encompass the entire software development life cycle, which can lead to incomplete or inaccurate results.

Other approaches related to Behavior driven development

• Domain Driven Design (DDD) - a software development approach that focuses on how the software interacts with the users, based on the concept of collaborating with domain experts in order to create a conceptual model which can be used to drive the design of the software.
• Acceptance Test Driven Development (ATDD) - a development process which focuses on creating acceptance tests for the software before it is developed, in order to ensure that the requirements of the customer are met.
• User Story Mapping - an agile development method which focuses on creating user stories and breaking them down into tasks in order to help the team understand the customer's needs.

In summary, Behavior Driven Development (BDD) is just one of the many approaches to agile software development, and there are other approaches such as Domain Driven Design (DDD), Acceptance Test Driven Development (ATDD) and User Story Mapping which may also be useful for developing software.

Behavior driven development — recommended articles

Feature-driven development — Product backlog — MoSCoW technique — Concept engineering — PMBOK framework — Sprint backlog — Project lifecycle — Quality Function Deployment — CMM model

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.