Three key points in TDD

Test-driven development is very simple.
1. Write test code
2. Run the test case and find that the test case fails.
3. Add a small amount of implementation code
4. Run the test case. The test case passes
5. Reconstruction

There are three key factors: Testing, rhythm, and drive.

Test-driven development should first talk about testing. Previously, in a project, I needed to write a computing class with very complex services. At that time, I had no confidence in writing data, mainly because the situation was too complicated and there were many branches. It involves expression parsing, reference relationships of custom variables, and summary calculation of data. At this time, it is difficult to ensure the correctness of the Code by using the traditional development method. The bad case is that bugs in the background computing class can only be tested on the interface. Later, I decided to adopt the test-driven development method. First I constructed the case and then wrote the implementation code. On the one hand, we can analyze the functions of this module from the perspective of use cases. More importantly, we can ensure that the computing class has a low Bug rate.
On the basis of the test code, we are more confident in implementing such a requirement. Besides, checking the internal logic of complex programs is much more complicated than checking test cases one by one.
Refactoring is based on having test code.

The pace determines the efficiency. From the five steps of test-driven development described above, we can clearly see a sense of rhythm. If you use a popular testing framework, such as XUnit, you can see the red-green alternation during running. (Red indicates that the use case has not passed, and Green indicates that the use case has passed ). In addition, the five-step cycle is usually measured in minutes.
With a good pace, we can effectively support the practice of Pair programming.
The concept of Pair programming is easy to understand: two people share one computer to write code. However, you may encounter many problems in practice.
In the past, two people were not "co-production" during Pair programming. This means that one person is writing code, and the other person is "thinking" or "in a daze ". Sometimes I think that one of them is too tired to write code, and I will replace it with another one. Or one person is always writing code, and the other is always tutoring.
TDD has a rhythm problem. A task is divided into red bars and green bars. The pair of two people focused on "red-green alternation. In this way, we can ensure that the steps of the two are consistent. Both parties know that we have achieved the first step. Generally, you can write test cases by yourself and implement them by another person and then exchange them.
How to Write use cases that make the other party wrong, and how to prevent your code from being vulnerable. Development is carried out in this cooperative and competitive interactive game.

After realizing the benefits of testing and pace, we recently found that TDD is closely related to simple design.
If the "driver" effect can be achieved, no redundant code is required for a row of test cases, and no structural design is required without case proof. In this way, the art that maximizes the work that has not been done is the core of simple design.
It does not mean that no design is required, but that the intent of the design must be proved by corresponding use cases.

Trackback: http://tb.blog.csdn.net/TrackBack.aspx? PostId = 752613