I have read a book about test-driven development, some excerpt and feelings:
TDD's ultimate goal: Cleaning and available code Clean Code That Works
Test-driven development of the opposite: Architecture-Driven Development TDD first solves the available problems, then considering neat, add the ADD.
TDD workflow: (1) Write a test program (2) Let the test program compile (3) run the test program, find that you cannot pass (4) to allow the test program to run (5) eliminate duplicate design, optimize design structure personal understanding : (1) In order to easily write test procedures, it is often necessary to write the meaning of the Signature (2) step 4 of the measured program function to "modify the measured schedule to meet the assertion requirements of the test program." (3) Step 5 is also important, indicating that the TDD does not deny the importance of good design, just the problem in the process, that is, TDD thinks: should first make the code work, let the code more tidy.
Dependencies and repeated design dependencies are key issues in software development in various sizes. Example: Use a database vendor's SQL dialect that causes the system to rely on the database product and cannot be ported to other database systems.
If there is a problem with dependency, the performance is repeated design. Duplicate design is a replicated logic design, that is, the same code appears in multiple places.
Eliminating duplicate design is to eliminate dependencies.
TO-Do List working method: List the tasks that need to be completed, and do one by one. Avoid excessive clues affect the whole god of current issues.
Triangulation Triangulation is one of the ways to test the test, allowing the other two ways to test to run to: pseudo implementation and obvious implementation. The triangulation is the most conservative implementation method of TDD. Implement only when the test case reaches 2 or more, and the second CASE requires a more general solution (generalized / abstraction?). Core thinking is: What changes need to be supported when designing, if you don't see new needs, don't modify existing code.
Reconstructing TDD for refactoring a "always doing, a little one thing". "Code for tomorrow, design" (the textbook said "" Code "is today, design as tomorrow") "Not for the code, your code is more likely to adapt to future needs" personal understanding: If you do it again Many, it may cause excessive design; if you don't do it, you will be afraid when you are forced to do.
Limitations of TDD: Do not expect TDD instead of other types of tests: performance test, security test, pressure test, availability test. UI test is not suitable. The principle of TDD is to write test code and then realize the current code, so don't expect TDD in a large number of projects that have been encoded.
