BDD (behavior-driven development)

The focus of BDD is to gain a clear understanding of the expected software behavior through discussions with stakeholders . It expands the test-driven development approach by writing non-programmer-readable test cases in natural languages . Behavior-driven developers use the native language of a unified language in a domain to describe the purpose of their code. This allows developers to focus on how the code should be written, not on technical details, but also to minimize the cost of translating the technical language of the code writer to and from the domain languages of business customers, users, stakeholders, project managers, and so forth.

Different organizations use different names, or different definitions, about how to deal with requirements descriptions and tests, but they all have a common set of core principles and ideas, and when you accept him, we can assume that they are essentially the same. It is usually defined as follows:

Agile Acceptance Testing
Acceptance Test Driven Development
Instance-Driven development
User Story Test
BDD behavior-Driven development
Instantiation Requirements Description (specification by Example)
For the above concepts, I think we are not unfamiliar, but may be a concept, because there is no practice. When specific to practice, in fact, we find that the process is relatively easy to understand, but the way is not the same, or the implementation process is not the same, of course, here to say is different, that is the method. Methods are summed up, after more practice, refined out is suitable for our method. Just as we've been implementing it for a while, and suddenly one day someone asked me what is BDD (behavior-driven development), I find I'm confused, I don't understand. But I think that the process I'm doing now is not a BDD, and the process I'm doing right now is defined as an instantiation requirement, but the concept doesn't seem to pull in development and testing, and using BDD to define it, it seems that the requirements, design, development, and testing are tied together in a flash.

　　What is BDD? In fact, it is through the behavior of real users to define what we need to develop what kind of products, personal understanding. But then combined with the requirements of the instantiation, we will find that we are the user's behavior through an instance of the process of description, and then organized into design, development and testing can understand, of course, the most important is the user can understand, and the user after the recognition, this is what I want, this is BDD, which is the instantiation of the demand process.

It is neither a traditional requirement document, nor a design document, nor a test case document, but it applies to every stage of demand, design, development, and testing, and from the perspective of the user. Then I think that's the process pattern we want.

This session will introduce the basic process of instantiating the requirements process

The following are the main process patterns for instantiating requirements descriptions:

　　

When we get a business goal, we will follow the above flowchart to produce an instantiation of the requirements process

Get the scope from the target
With the user-supplied description of the requirements, we turn these descriptions into another user-understandable and real-user behavior that introduces the concept of user story users ' stories. Then start with the customer's business goals, and then define the scope of the goals by collaborating. The key here is to communicate more closely with the user, through continuous refinement, to confirm that this is the user's desired function.
Develop requirements statement from collaboration
The purpose of this collaboration is to create a requirement statement that is designed to involve the needs, design, development, and testing, and to bring the team's knowledge and experience into full play, so that the stakeholders of the project are more involved in the delivery process.
Examples Show
For example, it is necessary to communicate the needs of the project, the different functions of the team have, and each person's business background is different, by way of illustration can make the goal more consistent.
Refining Requirements Description
Development discussions in the collaborative process can build consensus in the relevant areas, but the resulting instances often contain many unnecessary details. The critical instance must be streamlined. The process of refining the requirement description, in fact accompanied with the production of the instantiation requirements, and these refined examples can be regarded as the acceptance conditions of delivery.

Frequent validation
Frequent validation is based on the need to refine requirements, which is the work that must be done repeatedly in all process implementations. The requirements are frequently verified by frequent validation with the user, and the design is frequently verified by instantiating the requirements to meet the needs of the user, developing frequent validation of the business logic in the code through instantiation requirements, and testing the functionality of the delivery frequently by instantiating requirements and as a basis for final acceptance testing.
Evolve a Document System
Through these processes, the final evolution of a document system. The reason is called the document System, mainly embodies its reliability, authority. All design, development, change and testing process are considered as the starting point, and timely updating, long-term maintenance.

The core of the instantiation requirement process is to stand with the user, from the beginning of communication, continue to examples, refinement, streamlining to unified confirmation.

BDD (behavior-driven development)