Is your project TDD ready? Some Ideas about test-driven development

Definition of test-driven development in Wikipedia
Development) is a modern computer software development method. Use testing to drive the design and implementation of software programs. The test driver became popular in 1990s. Test-driven development
Restrict the program development methods advocated in programming. The method is to first write the test program and then code it to pass the test. The purpose of test-driven development is to get quick feedback and use the "pull strate"
The main line method to build the program.

 

If you are not familiar with test-driven development, the following lists some practical steps for test-driven development. Because test-driven development is also a periodic iteration, these steps are all cyclically performed.

 

1.Add a test case
Before developing a new feature, you must write one or more test cases for this feature.

2.Execute all test cases
The newly added test cases should fail during execution, because we have not started developing function points.

3.Write function code

4.Re-execute all test cases
If the test still fails, modify the code until all tests pass. We assume that the Code meets the functional requirements (or your test code is written in White ), however, the quality and efficiency do not necessarily meet the requirements.

5.Refactor your code

After completing these steps, start a new iteration and develop new functions.

 

First
First, as a developer (programmer), to be honest, I am relatively passive in testing-driven development. I don't want to write a bunch of test code before I start writing functional code.
Looking at the test code, we can see a large piece of red bars to test failure, and then try to write code to turn the red bars one by one into green. Isn't that silly, even if the test fails
What if they fail? Why do I need to prove that I am wrong before I start to implement it successfully? Why can't I go with myself? Haha

 

Now let's look back at the original intention of the Revolutionary Pioneers to create test-driven development?
What is the problem solved? According to the above definition, the purpose of the test-driven method is to obtain rapid feedback, that is, to reduce the detours of software development, and to avoid excessive design and
Over-implementation. If every developer can strictly follow the steps mentioned above for development, and each function point can write a sufficient number of quality tests, then the TDD result must be
You can even use a full-time tester. However, I am afraid this is only the wishful thinking of the management layer. Developers, at least some developers, are not willing to bother themselves.

 

One of the projects I 've experienced has performed TDD development for a while, but the results are of course difficult to come up with. The following is a summary of the problems in the TDD practice process, I hope it will be helpful for people who want TDD and want to know TDD.

1. Developers are not highly motivated to abide by the TDD process. They cannot guarantee that they do not want to write test before writing code.

2. it is too costly to comply with TDD. For example, it takes about an hour to execute all the test tasks in our project. If all the functional code is compiled and tested, there is almost no time to write code every day.

3. The quality of the test code is not high enough, and the coverage rate is not enough. Even if all tests are successful, there are still many problems in the system. I am afraid this is also normal. Who would like to add so much trouble to themselves.

4. When the demand changes frequently, the test code is not easy to maintain, and the test code cannot be changed first when there is a need to change. Sometimes the code has been changed, and the function is normal, but the test has not been changed. So that the project finally encountered a strange phenomenon. If the test fails during each execution, it is not a problem with the system, but the test is not updated.

 

Is TDD feasible? This is my idea of TDD. It is called the Blue Army and the Red Army.

 

1. Divide the development team into two groups. One Team is responsible for developing and testing code, that is, hypothetical competitor to the Blue Army. One Team is responsible for developing functional code, that is, the Red Army. The task of the Red Army is to ensure that its code passes the Blue Army test, and the Blue Army's task is to make its test cover all the scenarios and interactions in the application as much as possible. In this way, if the blue army passes the test, the normal functions of the system can be basically guaranteed.

2. Both teams develop test cases and function code for a function point at the same time, and submit the integration at the same time.

3. perform the test. If any test fails, the Red Army is responsible for modifying the code.

4. if you have a professional test team in the project, you can also test the function after a function point is completed, and submit the problem to the Blue Army, the Blue Army adds test code to the detected problems, and the Red Army ensures that the test code can pass.

5. After all tests are passed, you can start the development of the next Function Point.