TDD practice summary

TDD is a test-driven development. I recently read some instructions on how to writeCodeBooks, including the art of code modification and the clean code, all of which refer to TDD.

I remember seeing a book about extreme programming a few years ago in a bookstore, and occasionally heard about the concept of test-driven development. The general idea is to write test cases before implementing a function,

Write the code again, and then let the code pass the test case. The developed functions are improved through continuous iteration.

I have tried TDD before, and although it is also profitable, it seems that what I did at that time is not TDD. The main reason is that the granularity of my unit test is too rough, because it won't pile up, many branches and

The Logic cannot be implemented, and because a real environment (such as a real database environment) is required, the maintenance cost of the test code is high, and the test case runs for a long time.

These make TDD very difficult to continue. I think my unit test cases were more like integration test cases. In addition, such test cases are often one-time.

Recently, an important reason why I am interested in TDD is that I am currently debuggingProgramThe cost is much higher than before. If it takes at least two hours to discover and solve a bug in the real environment,

You certainly want the code to be removed before testing in the real environment. This is the value of TDD.

However, TDD cannot discover all the bugs. There are two types of bugs, and TDD is powerless:

The first is the interface layer with the operating system, or the interface layer of other third-party libraries. If the program includes the interface and interface-related code, this part of ut cannot be tested;

The second is the logic misunderstanding of the designer. When the expected result is wrong, UT will be powerless.

In addition, ut can be used to test the layer by piling, and the running time of each UT can be controlled in milliseconds.

I added a new function some time ago and used TDD to do it. I wrote more than 700 lines of test code and more than 300 lines of formal code. During the coding process, several

Bug, but debugging still encountered problems in the real environment. The problems encountered after analysis are the two situations mentioned above. Other bugs are solved before debugging.

Even so, it took me one day to start debugging and solve the problem. Without TDD, the efficiency will only be lower.

Another point is that TDD cannot completely replace design. Although TDD itself is a design process, there must be a preliminary design scheme before TDD is implemented.

In addition, if you want to write good code, TDD is not enough, you must be proficient in using various design patterns.