Test-driven Development fundamentals

Here is my personal understanding of test-driven development, if there is insufficient please correct me

• The general steps in test-driven development are
1. Write a test (basically not run or even compile)
2. Small changes make it possible to compile and run (Create a function stub that needs to be called, not implement, or pseudo--return a fixed value directly)
3. Gradually generalize the code (using variables instead of constant values)
4. Elimination of repetitive designs (extracted as common variables or functions) through changes
• I understand each step as follows (corresponding to the 4 steps above)

1. When writing tests, only from the main function perspective, regardless of the function I want to invoke the existence of, but directly write I want to call xx function, get xxx return value, etc.
2. 1th step of the code must be an error, at this time to modify the error, fill in the corresponding function declaration, blank function body, if necessary, a fixed return value
3. After the 2nd step of the change, the main function can be compiled and run, but the value in this calculation is written dead (pseudo implementation), at this time should be the fixed value of these write dead variable, and add the requirements of the calculation process, into the "true implementation"
• This process cannot be urgent, modify part of the pseudo-implementation every time, and then test
• If the test does not pass when the true implementation is attempted, replace the part that is not sure to the pseudo implementation and re-test
• The processes of the two implementations are repeated repeatedly until various pseudo implementations are eliminated
4. The 3rd step of the changes, you can think that the development of the test is complete, the rest is the optimization problem, in the process of gradually turning the pseudo-implementation into a true implementation will leave some repetitive design, that is, some code snippets or values in multiple places repeatedly, can be extracted as a public variable or function, so as to optimize the structure
• Attention! Run the test every time you make a minor change, and roll back if you have a problem

• Experience
• You can see that the whole process needs to run tests over and over again, and if a test runs for a long time, it inevitably leads to very low development, so you can write different levels of testing, write for different big functions and small functions, rather than running the biggest test that involves the most each time.
• Writing tests is bound to take a little time, but once written, incrementally changed, and later maintained, you can reuse the remaining tests, so it's worth it from the big picture.

Test-driven Development fundamentals