Talking about Test Drive Development (TDD)
content:
Background 1. Advantage 2. Principle 3. Process 4. Principle 5. Test Technology 6. TIPS Reference About the author's evaluation of this article
subscription:
DeveloperWorks News DeveloperWorks Subscribe (Subscribe CD and Download)
Level: Intermediate
Li Qun
(Liqun@nsfocus.com) www.ihere.org November 2004
Test Drive Development (TDD) is an important feature of extreme programming. It has been developed by continuous testing, which simplifies the code and ensures software quality. From the perspective of developers, this paper introduces TDD advantages, principles, processes, principles, test technology, tips and other aspects.
Background A high-efficiency software development process is critical to software developers, which determines the development of painful struggles, or the joy of continuous progress. The Chinese people disdain for software blue-collarments, which is not resistant to cumbersome and long traditional development processes, making most developers. Recently, some software development processes related technologies provide some more efficient, practical software process development methods. Among them, a key technology is test drive development (Test-Driven Development). Although TDD light is greater than extreme programming, test driver development can be applied separately. The following is an introduction from the perspective of developers, so that developers use the least cost as soon as possible to understand, master, apply this technique. The following is discussed below, principles, processes, principles, test technologies, TIPS and other aspects. 1. The basic idea of advantage TDD is to promote the entire development through testing. The test drive development technology is not just a simple test work. Demand is always the most difficult description, and easy to change during software development. The need to say here is not only referring to the needs of the user, but also the need for the use of the code. Many developers are most frustrated by modifying a class or function interface for modifying or expanding, why do this happen because this part of the code is not well described. The test drive development is to write the test case, first consider the requirements of the code (including functions, procedures, interfaces, etc.), and this description is no-sense, executable. Decomposing this part of the test case, the decomposition, usage process, and interface of its function is designed. Moreover, this design from the use angle is usually more in line with the needs of later developments. Testable requirements, the improvement and multiplexing of the cohesiveness of the code is very beneficial. Therefore, the test drive development is also a code design process. Developers usually have a very bored written document, but to use, understand the code when understanding the code of others, I hope to have a document. The test case code produced during the test drive development is the best explanation for the code. The foundation of happy work is to have confidence in yourself and have confidence in your work. Many developers are often worried: "Is the code correct?" "How hard writing code has no serious bug?" "The new code of modification has no effect on other parts?". This fear even causing some code to modify the point of modification. The test set provided by the test drive development can be used as the source of your confidence. Of course, the most important function of testing drive development is that the correctness of the code can quickly discover, positioning bugs. Rapidly discovery, positioning bug is a dream of many developers. For the test set of critical code, and the continuous test case, the positioning bug provides conditions for the rapid discovery. My function is very complex code to use TDD development, only a few bugs are found in real environment applications, and they are quickly located. After you apply, it will definitely increase, improve, improve, quickly discover, locate BUG's ability, like this technology. So what kind of principle, the method provides these benefits saying? Let's take a look at the principle of TDD. 2. Principles The basic idea of test-drive development is to write test code before developing functional code. That is to say, first think about how to test this feature after clearing to develop a certain feature, and complete the test code, and write the relevant code to meet these test cases. Then loop the addition of other functions until the development of complete features. We will extend this technology from the code from the code to the entire development process. Test drivers at all stages of the entire development process should be tested. First, think about how to test, verify, assess, and write related test documents, and then start the next step, and finally verify the relevant work. The following figure is a comparative popular test model: V test model.
[Figure V Test Model] In various stages of development, including demand analysis, profiling, detailed design, and encoding process should consider the corresponding test work, complete the design, test plan, test plan of the relevant test case, test plan. The development phase mentioned here is only an example and adjusts according to the actual development activities. Related test documents are not necessarily a very detailed and complex document, or inform, but should develop the habit of testing drivers. About the test model, there is an X test model. This test model, I think it is to model the detailed stage and the coding phase, and it should be said to describe the development behavior of the detailed design and coding phase. And test drive development for a function. [Figure X Test Model] Basic principle should be said to be very simple, then how to do active operation, the development process is described in detail below. 3. Process software development of other phases of test driver development, complete the corresponding test documentation according to the idea of test-driven development. The following is an introduction to the detailed design and coding phase. The basic procedures for test-driven development are as follows: 1) Clear the functionality that is currently completed. You can record a list of TODOs. 2) Quick completion of test cases for this function. 3) Test code compilation is not passed. 4) Write the corresponding function code. 5) Test passed. 6) Reconstruct the code and guarantee the test. 7) Cyclic completion of all functions development. In order to ensure that the entire test process is relatively fast and convenient, you can usually use all test cases for test framework organizations. A free, excellent test framework is a XUnit family, and almost all languages have corresponding test frames. I have written an article introduction to CPPUnit (http://www-900.ibm.com/developerworks/cn/linux/l-cppunit/index.shtml). During the development process, the test code and function code are usually stored, where a simple test framework is provided, you can use it to understand the use of the test framework. Here is a list of files. Project / Project Home Catalog Project / Test Test Project Home Directory
Project / test / testseq.cpp Test SEQ_T test file, modify the test file for other function files
Project / Test / Testseq.h
Project / Test / Makefile Test Project Makefile
Project / test / main.cpp test project's primary file, no need to modify
Project / main.cpp project master file
Project / seq_t.h function code, tested files
The main process of the Project / Makefile project is basically the case, but you have to test your code easy to test, comprehensively and not tedious test, still have a lot of test principles and technology needs to be considered. 4. Principles test isolation. Different code tests should be isolated from each other. Testing to a piece of code only considers the test of this code, do not consider its implementation details (such as the boundary condition of other classes). a hat. Different work in the development of developers, such as: writing test code, development function code, reconstruction of code. Do different things, bear different roles. Developers should keep attention in the current work, not too much to consider other details, and ensure that there is only one hat on the head. Avoid consideration of excessive details, unseained complexity. Test list. There is a lot of function points for testing. When you want to add a functional demand problem at any stage, you should add the relevant function points to the test list and then continue working. The corresponding test case, function code, and reconstruction are then complete. One is to avoid omissions and avoid interfere with the current work. Test driver. This comparison core. Complete a feature, a class, first write test code, consider how it is used, how to test it. Then design, encodes it. Write an assertion first. When the test code is written, the assertion statement for the judgment of the function code should be prepared, then write the corresponding auxiliary statement. Testability. Functional code design, which should have strong testability when developing. In fact, the code that follows the better design principles has better testability. For example, the relatively high cohesiveness is as high as the interface. Timely reconstruct it. Whether it is a functional code or test code, the structure is unreasonable, the repeated code, etc., after the test is passed, the reconstruction is performed in time. With regard to reconstruction, I will write another detailed analysis. Small step forward. Software development is a very high complex work. Many things should be considered during the development process, including the correctness, scalability, performance, etc., many problems are caused by the complexity. Extreme programming puts forward a very good idea to move in small steps. Decompose all scale, high complex work, break down into small tasks. For a class, a function is completed, and if it is too difficult to decompose. The completion of each function takes test code - function code - test - reconstruction cycles. Reduce the complexity of the entire system development by decomposition. This effect is very obvious. After a few small function code is complete, the big function code can be passed without debugging. The implementation of a class method, soon seeing the entire class quickly complete. I felt that many features need to be increased, so I will see there are not a few. You will even be shocked by this speed. (I understand that this speed of debugging, error time) 5. Test technology 5.1. Which function is tested in the test range, particle size? Will it be too cumbersome? When can I stop testing? These issues are more common. According to the Master Kent Benk, the code you think should be tested will be tested. That is to say, I have to believe my feelings, my own experience. Those important features, the core code should be tested. I feel fatigue should stop taking a break. I don't have a more detailed test, stop this round of testing. Test-driven development emphasizes testing and should not be a burden, but should be a way to help us reduce workload. And for when to stop writing test cases, it should be based on your experience, functional complex, core function, should write more comprehensive, meticulous test cases, otherwise the test flow can be. There is no static standard in the test range, and it should also be changed over time. For the start of the feature code that has not prepared enough test, with the occurrence of the bug, according to the test case of the bug complement.
The principle of small step forward, asking us to test a large function block, you should be separated into a smaller function block for testing, such as a class A use class B, C, should write A using B, C function Before the test code, complete the test and development of B, C. So, is it to test each small or small function? I think there is no need. You should use your experience, focus on those who may have problems, and feel that it is impossible to have problems, and then make up the test. 5.2. How to write test case test cases use the traditional test technology. The procedure is simulated as much as possible. A comprehensive test case should try to make a branch overlay, the core code is as possible to do the path overlay. Test data is tried to include: real data, boundary data. Test statements and test data should be as simple as possible, easy to understand. In order to avoid excessive dependence on other code, a simple pile function or a Mock Object is enabled. If the internal state is very complicated or the process should be determined instead of the state, verification can be verified by log string. 6. Tips have questions, "How is the correctness of test code? Is it written test code or write a test document?" This is not a circulation of "chicken eggs, egg genes". In fact, it will not be. Usually the test code is usually very simple, usually a few statements that are judged around a certain situation, and if it is too complicated, it should continue to decompose. The traditional development process usually emphasizes the test document. However, as the development rhythm has accelerated, the continuous change of user needs, maintains high-level (demand, summary design) test documentation, the lower level of test documentation is really too big. And the test code for verifying the correctness of the functionality in real time is the best document for the code. During the software development, in addition to complying with several principles mentioned above, a question requires paying attention is to guard against excessive design. When writing a function code, you should pay attention to completing the current function point, by testing, using the simplest, direct way to encode. Excessive consideration of the later expansion, other functions have undoubtedly increased excessive complexity and easy to produce problems. The detailed test driver development should be waited until the addition of these features. At that time, there is a set of test cases to make the foundation, and the related features are easily added to the continuous reconstruction. Reference
Recommended Kent Beck's book Test-Driven Development: by example, Chinese version is "test driver development" http://www.china-pub.com/computers/common/info.asp?id=14701 free, excellent test framework * Unit series, including: junit http://www.junit.org cppunit http://cppunit.sourceForge.Net/ I have written an article "Convenient Development Tool CPPUnit Fast User Guide" http: //www-900.ibm.com/developerworks/cn/linux/l-cppunit/index.shtml This article article "this or what, v or x?" http://www.sdbestpractices.com/documents/ Software test: Software test: non-negligible stage "http://develop/Article?cidnet.com/pub/disp/Article?columnid=291&articleid=37924&pageno=1" software test: V model, or x model? "Http://develop/article?columnid=291&articleid=37975&pageno=1" Unit Test Research Report "http://blog.aspcool.com/tim/posts/349.aspx Here Some related articles http://www.ihere.org/modules/newbb/viewforum.php?forum = 10 The code related to this article. About the author of Li Qun currently pays attention to the development, research of network security products; software development process. You can contact him via liqun@nsfocus.com.
