Chapter 1: Test Drive Development
1. Everyone knows how to test, but why have so many systems have not been tested? The reasons are as follows: "Test is not detailed enough" "" "" Test is "", "testing is often not conducted by programmers who write code,", "test writing staff, depending on the document or other things. Not the code itself "," test is not automatic "," I corrected the error in one place but introduced in other places. "
2. Test driver development solves all of these issues, and also adds some other questions: "The test is completed by the programmer, ensuring its tested,", "," comprehensive test overlay means any bug one If you appear, you can discover its location "," detailed test sets and programs to release it, so that the future will be easier to modify and expand in the future. "
3. The design will be more simple, the test itself helps to describe the system, and the daily builds are robust.
4. Programmer can get Positive Feedback when working, this is the actual proven that the work progresses smoothly.
5. Test-Driven Development, TDD is a development method: a detailed programmer test set of the committee; unless there is a related test, do not write any product code; first write tests; Decide how code you need to write.
6. Use the programmer test to test whether the behavior of the class is correct. It and unit tests are different, but they have different purposes. Writing programmer test is to define the meaning of the code work. In theory, test-driven development means you have a detailed test set (Test Suite). Since there is no product code unless there is a test of the product code, there is no product code because there is no code that does not exist for the test test.
7. One of the principles of extreme programming is not before writing any of the tests associated with it, do not write any function code. This ensures that everything in the system must be tuned (Testable), which is part of the security network that can be confident and courageous. All of these code are tested self-confidence give you the courage to perform reconstruction and integration.
8. Write a small amount of test first, then write enough code to pass by, then write some tests, then write some code, write test, write code, etc., and so on.
9. Decide which code you need to write by test, write the easiest but also works (Do The SimpleSt Thing That Could Possibly Work). Working with a small incrementation method, sometimes it is very pitiful, but it is very important, even if you can't think of the benefits and by-products.
10. Although the test code is written, there is no need to worry about a "to do list". Need to add a class or a method, the compiler will tell you. With more tests, you need to summarize the simplest code written and refactoring.
11. When writing a test, you need to eliminate the repetition (Code That SMELLS) that we introduced when we pass through. 12. A simplest example: Chinese version P6-P8 page.
13. Every time you do a small revision, you must need to recompile and pass, which gives us enough confidence and guarantee. To use your computer feedback to track our next steps. If we want to create a class, method, the variable, the system will tell us.
14. People engaged in XP and user descriptions (User Story), this is a agile model. As long as the model helps us develop software, then we will do it.
15. Some developers do not think about problems from test perspectives, using visualization techniques, using visual modeling technology; for people with test brains, we use TDD.
16.
use
TDD
To quickly verify that the model is valid, this is in line with agile modeling.
AM
"Proof of code" in "
Prove It with code
Practice method.
XP
with
TDD
Close-dependent, support each other.
