TDD and vtdd series (III): TDD Overview

What is TDD?
TDD is short for test-driven development, that is, test-driven development. The basic idea of TDD is to use testing to promote development, rather than simply testing. TDD is one of the core of extreme programming, but TDD can also be used independently.

TDD advantages
Clear requirements: in the software development process, requirements are often easy to change and difficult to describe. The overall requirements of the project will be further refined into the Code requirements, that is, each code unit has its specific functional requirements. The overall requirements are not clear, and the requirements of the Code are naturally not clear. Even if the overall requirement is completely clear, refining may result in unclear requirements for some code. TDD first writes the test code. The test code is actually an example of the use of the product code and a requirement description for the product code. This description is clear, unambiguous, and executable.

Clear design: By writing test code, the functions and usage of product code are designed. This design is carried out from the perspective of use and is more in line with the needs of later development. These designs limit the extended scope of the product code, so that the functions of each code unit are purified, improving the testability, maintainability, scalability, and reusability.

Document formation: Many programmers do not like to write documents, but they require documents when reading and using others' code. Even if you write your own code, it will be difficult to read and modify it after a while without a document. The test code is a detailed document that records the usage of the Code unit and the output of the input. The document is executable and verifiable. Even if the code is frequently updated, the document and the Code remain consistent.

Confident programming: If there is no test, is the code correct? If the code needs to be modified, will it affect other parts? The test set ensures that the code is consistent with what the programmer thinks. After the code is modified, executing the regression test will immediately check whether the original function is damaged and whether other code is affected to work more confidently.

Improve Efficiency: TDD first writes test code before coding. Each minimum function point can immediately verify whether the code is correct. Code errors can be detected and located in the first place, greatly reducing debugging. If there is no test, the debugging time after encoding is usually much longer than the coding time.
Mandatory test: TDD requires that the test code be written first and then the product code be written. This prevents the programmer from focusing on writing other code to ignore the test.

TDD principles
Independent Test: Tests of different codes should be independent of each other. One Class corresponds to one test class (for C code or C ++ global functions, one file corresponds to one test file ), A function corresponds to a test function. Use cases should also be independent. Each use case cannot use the result data of other use cases, and the results cannot depend on the execution sequence of use cases.
One role: the development process involves a variety of tasks, such as writing test code, writing product code, and restructuring code. When you do different jobs, you should focus on the current role. do not consider other details too much.

Test list: the code may have many functional points and the requirements may appear one after another. When you want to add a function at any stage, add the relevant functional points to the test list, then you can continue your work to avoid omissions.

Test-driven: development driven by testing is the core of TDD. To implement a function and write a class or function, you must first compile the test code to determine how to use the class, function, and test, and then design and encode the function.
Write assertions first: When writing test code, you should first write an asserted statement to determine the code function, and then write necessary auxiliary statements.

Testability: The product code design and development should be tested as much as possible. The functions of each code unit should be relatively simple. "Each class and function should only do what it should do. In particular, when adding new functions, do not add functions to the original code as soon as possible. For C ++ programming, we should consider using OO methods such as subclass, inheritance, and overload.

Timely reconstruction: If the structure is unreasonable and the Code with poor taste is repeated, it should be reconstructed in time after the test is passed.

Small steps forward: software development is a highly complex task, and small steps forward is a good way to reduce complexity.

TDD three military rules
Robert C. Martin, President of object meentor and senior consultant in extreme programming, proposed three rules for TDD:
1. Unless this permits failed unit tests to pass, no product code can be written.
2. Only unit tests that can cause failures can be written (compilation failure is also a failure ).
3. Only product code that can result in a failed unit test can be written.
The three military rules briefly and clearly describe the TDD process. The next section provides an example.