Some Opinions on TDD, BDD, and DDD

In actual projects, we may face different needs at any time. The elements of different aspects determine the development mode we adopt.

For example, how complicated is it? Are all requirements clear enough? Do developers have sufficient knowledge about related services? Is the project construction period reasonable? All kinds of problems. This also determines that we may need to adopt different development modes to meet different needs. Here are some examples.

 

1. TDD

TDD refers to test drive development, which obviously means test-driven development. That is to say, we can test the entire project from the test perspective. The general process is to first abstract the interface code for each function point, then write the unit test code, then implement the interface, run the unit test code, and cycle this process until the entire unit test passes. This is similar to agile development.

The benefits of TDD are naturally Needless to say. It allows you to reduce program logic errors and minimize project bugs. When we get started with programming, we often have such an experience, maybe you think it is perfect and you feel good about yourself, but only when testing or applying it can you find that there may be a bunch of bugs, design problems, or more serious logic problems, TDD can help us minimize the occurrence of similar events. In addition, some of the popular models currently support TDD very well, such as MVC and MVP.

However, not all projects are suitable for TDD. I think the following conditions must be met.

First, the project needs must be clear enough, and the programmer must have a sufficient understanding of the entire requirement. If this condition is not met, the execution process will inevitably be out of control. Of course, to achieve this goal, we also need to do some homework, which requires that our early demand analysis and HLD and LLD should be done carefully and well-developed.

Secondly, it depends on the complexity and dependence of the project. For a project with a complex business model and a strong dependency between internal modules, using TDD will fail, this results in a huge workload for programmers to split interfaces and write test code. In addition, because the dependencies between modules are too strong, we may not adopt some bridging modes when writing test code, which will inevitably increase the workload of programmers.

2. BDD

BDD refers to behavior drive development, that is, behavior-driven development. Here, B does not mean business. In fact, BDD can be regarded as a supplement to TDD. Of course, you can also regard it as a branch of TDD. In TDD, we cannot completely guarantee that the tests written according to design are the functions expected by users. BDD makes this part simple and natural, and describes it in natural language, so that developers, testers, Ba and customers can reach an agreement on this basis. Because the concept of test priority is not acceptable to everyone, some people may think that the system is too complex to test, and some people think that something that does not exist cannot be tested. Therefore, here we try to change a concept, that is, to consider its behavior, that is, how it should run, and then abstract the norms that can reach consensus. If you have used BDD frameworks such as jbehave, you will have a better understanding of the specific process. Here I recommend a specific article. Experience behavior-driven development in person.

In addition, the relationship between TDD and BDD can also be referred to this article: "href =" http://cache.baidu.com/C? M = Clerk & P = c4769a46d6951ff41cf6c4710e10d70a & newp = Clerk & User = Baidu & fm = SC & query = BDD % BF % Aa % B7 % A2 % c4 % A3 % Ca % BD & qid = a08e02971812316c & p1 = 13 "> virtual forum: code test ratio, test-driven development, and behavior-driven development

3. ddd

Ddd refers to domain drive design, that is, domain-driven development. This is a very good idea. When we first started learning the program or even the three-tier architecture, we were faced with many questions, such as how to implement our data layer? Later, we began to learn about MVC, MVP, and other architectures. How to Design the model layer became our new problem. We have seen too many such cases, and the model has become a simple data container, that is, the anemia model we often say. In fact, DDD is also built on this basis, because it focuses on the design of the service layer and business implementation, so it inevitably exists based on the anemia model. However, it is the biggest combination of analysis and design, and does not leave them in a split state. This is correct and complete for us to meet customer needs and to establish a model with business scalability, is very helpful.