When I first came into contact with BDD (Behavior-Driven Development), I thought I was writing scenario cases with tools such as cucumber to realize automatic testing, and even I couldn't tell the difference between BDD and ATDD (Acceptance Test-Driven Development) for a long time. So, is BDD really used for automated testing? This article will share my understanding of BDD with you.

"The hardest part of developing a software system is to explain exactly what to develop" ("The hardest part of building a software system is to refuse to build anything"-there is no silver bullet, Fred Brooks).

Scenario 1: Business analysts feel that the requirements they have analyzed have been clearly written and they have had enough communication with technicians. However, when they finished the development desktop check, they found that the developed functions still did not meet expectations.

Scenario 2: When the development team worked hard to develop a function and confidently showed it to the product manager/customer, it was found that the original function required by the customer was not like this.

Are these scenes familiar? Why is this happening? The first scenario is that there is a deviation between the technical staff in the development team and the requirement analyst, which leads to different requirements for everyone. The second scenario is that the development team does not really understand the real requirements put forward by the product manager/customer, which leads to the inconsistency between the developed products and the requirements. In fact, the real reason for these two inconsistencies is that different roles have different domain knowledge and speak different languages. If everyone uses their own domain language in communication, there will inevitably be a communication generation gap, which will lead to inconsistency in understanding.

Different domain knowledge and language barriers lead to communication barriers. How to solve this objective problem? BDD was born for this purpose.

Dan North, a supporter of BDD, stressed that BDD is not about testing. It is about writing use cases and expectations before the application exists, so as to describe the behavior of the application and encourage people in the project to communicate with each other.

It is difficult to give a clear and understandable definition of BDD, including the views of experts. Here, try to summarize the following points:

1. Pay attention to business domain, not technology: BDD emphasizes describing user behavior and defining business requirements with DSL (domain-specific language), without paying attention to the technical implementation of the system.

2. It is not a tool, but a way of collaboration: BDD requires all roles to participate in the mining and definition of system behavior in order to achieve a consistent understanding of business value.

3. It's not a test problem: BDD originated from TDD, which is different from TDD. The focus is not on testing, but it can guide better automated testing.

4. Full-stack agile method: BDD urges all roles in the team to cooperate and communicate with each other from requirements to final testing and verification to deliver the most valuable functions.

Given the description format of the use case scenario ... when ... and then ... "Everyone is familiar with it, but it is very difficult to write a good use case in this format, especially for beginners. The following points are for your reference:

According to the business process, find the corresponding data flow, vertically cut each data stop point or data change point, and extract a use case scenario. The following is an example of a real enterprise.

Example:

The employee creates a blank questionnaire in the enterprise system and sends it to the client. The client can see the questionnaire in the user system and fill it out. After submission, employees can see the completed questionnaire report in the enterprise system. The business process and data flow are shown in the figure below. According to the above method, four use case scenarios can be divided.

The description language of the scenario must be understandable by the business field and does not involve any technical details related to implementation. The described scenario must be abstracted from the business layer and reflect the real business value.

In order to promote development, the described use case scenarios must be easy for technicians to understand. In order to guide automated testing, it is also required to be friendly to the realization of automation.

This seems to contradict the first point, but we can still do it by strictly following the format requirements of BDD:

The -GIVEN clause describes the preconditions and initial state of the scene, usually the present perfect tense;

-WHEN clause is to take action or event, and it must be a verb, usually the simple present tense;

The -THEN clause uses "should be …" to describe an expected result rather than an assertion, which is more closely related to testing.

The requirements described by abstract business language are often too abstract and lack a lot of key information, which leads to different people's different understanding of requirements. If you want to abstract and contain detailed information, you need to describe it with requirements examples. Simply put, it is to explain the scenario use case. For example, you need to list data. If data examples are directly added to the description of scenario use cases, such use cases will be very confusing and have poor readability and maintainability. If we can substitute some variables in the use case describing the scene, extract the values (data) corresponding to the variables and save them as tables or independent files, the use case will be readable and convenient for later maintenance and modification. This is a data-driven method to describe the requirements of instantiation.

Here are a few examples for everyone to experience:

Scenario 1: Looking at the inbox, you can see that the third one is clear, can reflect the commercial value, and meets the above requirements.

Scenario 2: To restrict illegal users from viewing some restricted content, what (what) should BDD emphasize, not how (how). The second one is better.

Scenario 3: Add books to the shopping cart and calculate the total amount.

The tools of BDD include Cucumber, JBehave, Twist, Harmony, etc. There are a wealth of documents on the Internet for reference, so I won't introduce them here.

The function of BDD is to bring together different stakeholders, delivery teams and other project-related personnel to form a common understanding, values and expectations. It can help us:

1. Pay attention to user behavior

2. Provide the most useful functions

3. Maintain consistent terminology in the team.

4. Explore examples of requirements

5. Writing and maintenance requirements

6. Create a dynamic document

7. Remove obstacles to collaboration and communication.

-There is no need to use BDD, and the communication cost is low for simple one-off projects;

-For projects with light business and heavy technology, simple BDD can be used on the whiteboard, and there is no need to record requirements use case documents in BDD tools;

-For projects with complex business and many team members, communication costs are high and BDD is needed.

1.BDD and TDD/ATDD

TDD is test-driven development, and ATDD is acceptance test-driven development. They are all about testing and are closely related to the developed system. On the other hand, BDD is different. As mentioned earlier, BDD is not about testing, but about the needs and business value of customers. The requirement use case described can exist independently of the software system, because the customer's business always exists and does not depend on whether there is a software system to support it.

2.BDD and SBE

SBE(Specification By Example) was put forward by Gojko after BDD, and it is also about requirements, which mainly emphasizes finding missing concepts in requirements by enumerating examples. BDD also pays attention to requirements and uses examples to describe behaviors. There is no essential difference between the two, but only a conceptual difference.