How to make unit testing
Author: Joe yuan [2005/02/16]
Summary: The unit test is the basis of software testing. This paper discusses the two steps of unit testing of unit testing and dynamically performing tracking methods, the required work items and related strategies and methods. Through the description of these two steps, the author will infuse over the full text of many years of unit testing experience and test theory. Keywords: unit test, manual inspection, white box test, test case, tracking debug 1 Overview unit testing is a test work for the correctness of the minimum unit-program module for software design. Its purpose is to discover errors that may exist within each program module. The unit test is also a basic responsibility of the programmer. The programmer must maintain a serious attitude of the code you have written, which is one of the basic professional qualities of the programmer. At the same time, unit testing capabilities is also a basic ability of programmers, and the ability to directly affect programmers' work efficiency and software quality. The unit test is made during the encoding process, which is the smallest, and the return is particularly preferable. Consider test problems during the coding process, get better code, because you should do what you should do for the code at this time. If you don't do this, but I have been waiting until a module crashes, when you may have forgotten how the code works. Even under powerful working pressures, you must also re-put it clearly, this is a lot of time. Further, this is often not so thorough, it may be more fragile because you can't quote the understanding. Usually qualified code should have the following nature: correctness, clarity, normative, consistency, efficiency, etc. (sorted by priority). 1. The correctness means that the code logic must be correct and capable of implementing the expected function. 2. Clearness means that the code must be concise, easy to understand, and notes have no ambiguity. 3. Normative means that the code must comply with the common specifications defined by the enterprise or department include naming rules, code style, and so on. 4. Consistency means that the code must be named after name (such as: the same function is used to use the same mark), and the style is held uniform. 5. Efficientness means that the code must not only meet the above properties, but also need to reduce the execution time of the code as much as possible. 2 Unit Test Steps After the completion of the code, the unit test work is mainly divided into two steps artificial static check and dynamically perform tracking. Artificial static examination is the first step in test, this phase work is mainly to ensure the logical correctness of the code algorithm (try to detect the logic error of the discovery code), clarity, normative, consistency, algorithm efficiency. And found out no mistakes in the program. The second step is to track the comparative actual results to discover errors by using the test case. Experience shows that the use of artificial static examination methods can effectively discover 30% to 70% logical design and encoding errors. However, there will still have a large number of hidden errors in the code that cannot be discovered by visual inspection, and you must capture the debugging method. Therefore, the dynamic tracking debugging method has also become the key and difficult point of unit testing. 3 Manual examination usually performs the following items in the artificial inspection phase: First, check the logical correctness of the algorithm; determine whether the code algorithm written, the data structure definition (such as queue, stack, etc.) implements the module or method The required function. Second, the correctness check of the module interface; determines the number of form parameters, data type, whether the order is correct; determine the correctness of the return value and the return value. Third, the input parameters do not make a correctness check; if there is no correct check, it is determined whether the parameter does not need to perform the correctness check, otherwise add the correctness check of the parameters. Experience has shown that code that lacks parameters correctness check is one of the main reasons for the unstable software system. Fourth, call the correctness of other method interfaces; check the correct or not, the incoming parameter value is correct or not, and the number is correct or not, especially a polymorphic method. The return value is correct or not, there is no meanings indicating that the return value is. Preferably, the return value of each called method is properly checked, if an exception or an error program appears in the called method, the error should be given, and the appropriate error handling code is added.
Fifth, error handling; module code requirements can foreseen the conditions of error, and set the appropriate error handling so that once the program is wrong, the error program will be arranged to ensure the correctness of its logic, this error handling should be Part of the module function. If there is one of the following cases, it indicates that the error handling function of the module contains errors or defects: the description of the error is difficult to understand; the error is not sufficient to locate the error, not enough to determine the error, the error message and the actual error The reason is incorrect; the processing of the wrong condition is incorrect; before processing the error, the error condition has caused the system's intervention, etc. Sixth, guarantee the correctness of the expression, SQL statement; check the syntax of the written SQL statement, the correctness of logic. The expression should be guaranteed to not contain unssemblances, which can be enrolled for easy to generate ambiguity expression or operator priority (eg, =, ", &&, ||, , -, etc.) "The operator avoids erriness, so on the one hand, it can ensure the correctness and reliability of the code, and can also improve the readability of the code. Seventh, check the correctness of constant or global variables; determine the value and value of the constant or global variable used, data type; to ensure that constants each references the same value, numerical value, and type consistency. Eighth, the specification consistency of the definition of the character; ensuring that the variable is named to see the name, and simple but should not be too long or too short, the standard, easy memory, it is best to spell. It is assured to ensure that the same indicator represents the same function, do not indicate different functions; do not use the same representation to represent different functional significance. Ninth, the consistency of the program style; the code must be able to guarantee the corporate norm to ensure that all members of the code style, standard, and work. For example, a loop is made to the array. Don't use the subscript variable from the down to the next way (such as: for (i = 0; i ; i <10)), use from top to bottom to the next method (such as: for). = 10; i -; i> 0)); should try to use a unified manner, or unified from the bottom, or unified from top to bottom. It is recommended to use the for loop and the While cycle, do not use the Do {} while loop. Tenth, whether the mysterious number used in the check procedure uses a representation definition. Mysterious numbers include various constants, arrays, character positions, transform factors, and other values written in text in text. In the program source code, a number of original forms has no indicative information on its own importance or function, which also leads to difficulties to understand and modify. For such mysterious numbers, they must be represented by corresponding scales; if the number may be used in the entire system, it is important to define it as global constant; if the mysterious number is used in a class, it can be defined as class properties ( Attribute), if the mysterious number is only defined in a method, it is necessary to define it as a local variable or constant. Eleventh, check whether the code is optimized, whether the algorithm efficiency is the highest. If the SQL statement can be optimized, whether or not to use 1 SQL statement instead of the function of multiple SQL statements in the program, whether the loop is necessary, whether the statement in the loop can be extracted outside the loop. Chapter 12, check if your program is clear and simple and easy to understand. Note: The lengthy program is not necessarily clear. Thirteenth, the inspection method is complete; if it is clear and simple; whether it correctly reflects the function of the code, the wrong comment is worse than the comment; if you do an extra comment; if you know the code, you know the code. Necessary note. Fourth, check if the comment document is complete; if the note, class, attribute, method function, parameter, return value is correct and easy to understand; if it will fall or more comments, the parameter type is correct, Whether the limit value of the parameter is correct.
Especially for the formal parameters and the return value about mysterious numerical notes, such as: Type parameters should point out 1. What is the representative, 2. Represents, 3. Represents what to wait. For comments for returning result sets, you should have the result set contains those fields and field types, field sequence, and so on. 4 Dynamic execution tracking dynamic execution tests are usually divided into black box tests and white box tests. Black box test refers to the functional design specifications of known products, which can be tested to prove whether each implemented function meets the requirements. White box test refers to the internal work process of known products, which can prove whether each internal operation meets the requirements of design specifications, all internal components have been checked. For unit testing, the white box test method should be used to track inspection and testing of each module. For unit white box testing, the program module should be checked as follows: 1. Test at least once in all independent execution paths in the module; 2. Take the "true" and "false" of all the logic. At least Execute it; 3. Perform a cyclic body within the boundary of the loop; 4. Test the validity of internal data, etc. Unit white box tracking tests, usually need to do the following three work: 1. Design test use case; 2. Design test class module; 3. Track debugging. 4.1 Test case design Usually dynamically performs tracking debugging is done at the coding phase. Design of test cases for unit testing can begin after the source program is static manual inspection. Using the design documentation, you can verify the program function to find multiple test cases of the program error. 4.1.1 Design of test cases The basic principle of design test use cases Basic principles are: 1. A good test case is that it can find errors that have not been discovered so far; 2. The test case should be input to the input data and the corresponding expected output result. These two parts are constituted; 3. When designing the test case, the reasonable input condition and unreasonable input condition should be included. 4.1.2 Test cases for white box test Design White box test test cases generally use logical coverage and basic path law for design. First, logical coverage logic coverage is a test case design technology based on the logical structure within the program, which requires tester to understand the logical structure of the program. Logical coverage can be divided into: statement override, determination override, conditional coverage, determination - conditional coverage, conditional combination override and path coverage. 1. The statement coverage is to design a number of test cases, run the measured procedure, so that each executable statement is executed at least once. 2. Decideting the overlay is a designed a number of test cases, run the measured procedure, so that each judgment of each judgment in the program has experience at least once. 3. The conditional coverage is to design a number of test cases, run the measured procedure, so that each of the programs per condition in the program may perform at least once. 4. Decision - Conditional coverage is to design enough test cases, so that all of each condition in the determination is at least once, while each of the judging all possible judgment results are also executed at least once. 5. Conditional combination is designed to design enough test cases, run the measured procedure, so that all possible conditions for each judging are performed at least once. 6. Path Test is to design enough test cases to overwrite all possible paths in the program. Each coverage method has its own advantages and disadvantages, and the six coverage methods, as shown in Figure 1: Figure 1 typically selects the overlay method according to the complexity of the code module when designing the test case. The general code complexity is proportional to the complexity of the test case design. Therefore, the designer must do a singleness, high cohesiveness of the module or method function, make the method or function code as simple as possible; this will greatly improve the easy degree of test case design, improve the level of coverage of test cases. Second, the basic path method The basic path test method is based on the procedure control flow map, and the basic executable path collection is derived by analyzing the loop complexity of the control structure, thereby designing the method of testing the test case. Designed test cases To ensure that each executable statement of the program in the test is performed at least once. The basic path test method includes the following five aspects: 1. Control flow diagram of the program: a diagram method for describing the program control flow.
2. Program environment complexity: MCCABE complexity metrics; from the loop complexity of the program derive the number of independent paths in the base path set, which is the test case required for each executable statement in the program. Number of upper bounds. 3. Export test cases. 4. Prepare test cases to ensure that each path in the basic path is set. 5. Graphics Matrix: It is a software tool that serves a secondary action in the basic path test, and it can be used to automatically determine a basic path set. In addition, for the choice of test cases, the usual use of boundary value analysis, error speculation method, and other commonly designed methods, in addition to satisfying the selected coverage degree (or overlay). The boundary value analysis method is used to design reasonably input conditions and unreasonable input conditions; the conditional boundary test cases should include the boundary and conditional boundaries of the input parameters (if, while, for, switch, sql where clause, etc.). Error estimation method, list all possible errors and special circumstances that are easy to occur in procedures, selecting test cases in accordance with them; in coding, you can find a lot of common errors and suspected errors, for these errors, And design the corresponding test case. 4.1.3 Unit Test Plan Form You can refer to the following table, which is scheduled to prepare a test plan for each class (or module or package). Table 1 is a header for each class (or module or package) as a test plan, which indicates that this test plan is for that module and related files. Table 2 is a sub-table corresponding to Table 1 specifying the module test case, each test case can have a sub-table; the unit test result sub-table is filled in according to the actual results when the test case is performed. Sub system name. PackageName. JavaClassName unit test plan
Identification format: "Sub System Name. JSP_FileName" or "Sub System Name. PackageName. JavaClassName" component function items such as: Components Complete "Add Post" function for Summary / Detailed Design File names: 1.1 Release Partial Detailed Design Manual Physical File Name JSP_FileName; PackageName. JavaClassName Table 1 Unit Test Child 001 The following table is a table for the top table "Subsystem name. PackageName. Javaclassname" For each test case with a sheet:
Number .001 Note: ". Number" section To start from 001 to 999, personal number programming program is as: Ge Zhichun tester such as Ge Zhichun test, such as: Description of error logic input inspection test content, for Public int FUN3 (String P1, INT P2) input test , Method return -1; output expectation return-1
Unit test results
The actual input data P1 = NULL actual processing case is not verified by P1 == NULL, and NULL POINTER exception occurs when it runs to the p1.aaa () method. The actual output does not write logfile files; Test Conclusion Normal / Executive Table 24.2 Test class Design A module or a method is not a separate program. When considering testing it, you should consider it and the external connection, with some auxiliary modules To simulate other modules associated with the module of the module. These auxiliary modules are divided into two: 1. Drive Modules: The main program equivalent to the measured module. It receives test data to transmit these data to the measuring module, and finally output the actual test results. 2. Pile Module (STUB): Used to replace the submodule called by the module. The pile module can do a small amount of data operation, do not need to bring all the functions of the sub-module to, but do not do anything. The measurement module interested in the drive module and the pile module constitute a "test environment" as shown in Figure 2. The writing of the drive module and the pile module will bring additional overhead to the test. Because they are not delivered as part of the product when software delivery, and their writing requires a certain amount of work. In particular, the pile module cannot simply give information about "once enters". In order to be able to get the correct test software, the pile module may need to simulate the function of the actual sub-module, so that the establishment of the pile module is not very easy. Figure 2 The test environment of the unit test is difficult to write the pile module. In fact, it is also possible to avoid writing the pile module; just prepare the code writing work of the actual pile module when the project progress management is required to write before the module. And this can improve the efficiency of the test work, improve the test frequency of the actual pile module, and ensure the quality of the product more effectively. However, in order to ensure that it is possible to provide a stable and reliable actual pile module to the upward level, the driving module is still indispensable for subsequent module testing. For each package or subsystem we can write a test module class based on the prepredity test case to do a drive module for all the to be tested in the package. It is best not to test all the methods in the tracking class without using a method of testing a test function in each class. This is the benefit of: 1. You can test all the methods or modules in the package at the same time, or you can easily test the specified module or method. 2. Can use all test cases to perform tests for the same paragraph code to discover problems. 3. Test the regression. After a module is modified, all measured modules or methods can be performed as long as the test class is executed. This can not only be easily inspected, track the modified code, but also check the impact of modifying the relevant modules or methods in the package, making the modification introduced errors to find in time. 4. Re-use the test method to keep the test unit persistence and can write related tests with existing tests. 5. Separate the test code with the product code, make the code clearer, concise; improve the maintenanceability of the test code and the test code. 4.3 Tracking debugging tracking debugging is not only the best way to test the code in-depth test code, but also a favorable tool for program call to find erroneous roots. After the test class is designed, it is best to track the logical error of the debug code segment with a deep inspection code with an in-depth check code. Existing code development tools (such as: jbuilder) generally integrate this type of troubleshooting tool. The tired tool is generally consisting of executing a control program, performing a status query program, and a trace program. The execution control program includes breakpoint definitions, breakpoints, single-step execution, breakpoint execution, condition execution and other functions. Performing status query programs include queries of registers, stack status, variables, code, and the like related state information related to the program. Tracking programs are used to track event sequences (such as branch, subroutine calls, etc.) experienced during the tracking program. Programmers can identify, locate and correctly identify, positioning, and corrections by program errors by discriminating various states in the program execution.
