The Law of Construction-----Unit test

first, the importanceTesting is often a very tiring activity for programmers. What does the test bring to us? It is important to understand that testing cannot guarantee that a program is completely correct, but testing can enhance our confidence in the integrity of the program, which allows us to believe that the program did what I expected it to do. 　　Testing allows us to find bugs and deficiencies in our programs as early as possible. The longer a bug is hidden, the greater the cost of fixing the bug. 　　A large number of research data have been quoted in the book "Rapid Software Development" to point out that the cost of modifying a bug at the end is 10 times times the cost of modifying it when the bug is generated. Of course, we are mainly talking about unit tests. Unit testing is a method-level test and the most granular test. Each method used to test a class has satisfied the functional requirements of the method. In development, for a module that you have developed, you can only submit it to the SVN repository or Git repository after you have passed the unit test.

Normally qualified code should have the following properties: correctness, clarity, standardization, consistency, efficiency , etc. (sorted by priority).

1. Correctness means that the code logic must be correct and capable of achieving the expected functionality.

2. Clarity means that the code must be concise and understandable, with no ambiguity as to the accuracy of the annotations.

3. Normative means that code must conform to the common norms defined by the enterprise or department, including naming rules, code styles, and so on.

4. Consistency refers to the code must be named (such as: the same function of variables as far as possible to use the same identifier), style is consistent.

5. Efficiency refers to the code not only to meet the above properties, but also to minimize the execution time of the code.

second, unit test steps

After the code is written, the unit test work is divided into two steps: manual static Check and dynamic execution tracking .

　　manual Static Check is the first step of testing, this phase of the work is to ensure the logical correctness of the Code algorithm (as far as possible through manual detection of Code logic errors), clarity , standardization , consistency and algorithm efficiency . And as much as possible to find errors found in the program.

The second step is to find errors by designing test cases and executing the program to be tested to track comparisons between actual and expected results . Experience has shown that the use of manual static inspection can effectively detect 30% to 70% of logical design and coding errors. However, there are still a large number of hidden errors in the code can not be seen through visual inspection, must be carefully analyzed through the tracking debugging to be able to capture. Therefore, the dynamic tracking and debugging method has also become the focus and difficulty of unit testing.

Manual static Check Steps

Activities for the following items are typically required during the manual inspection phase:

First, check the logic correctness of the algorithm, determine whether the code algorithm written, data structure definition (such as: queue, stack, etc.) implements the functions required by the module or method.

Second, the correctness of the interface of the module check; Determine the number of formal parameters, data type, order is correct, determine the return value type and the correctness of the return value.

Thirdly, the input parameters have not been checked for correctness, if the correctness check is not done, it is necessary to determine whether the parameter correctness check is not required, otherwise please add the correctness check of the parameters. Experience shows that the lack of parameter correctness check code is one of the main causes of software system instability.

The correctness of invoking the other method interface, checking whether the argument type is correct or not, whether the passed parameter value is correct or not, the number is correct or not, especially the method with polymorphism. The return value is correct or not, there is no misunderstanding the meaning of the return value represented. It is best to check the return value of each called method with the explicit wet code for correctness, if the called method is abnormal or the error program should give feedback and add appropriate error handling code.

Error handling; Module Code requirements can anticipate the conditions of error, and set appropriate error handling, so that in the event of a program error, the error program can be re-scheduled to ensure the correctness of its logic, this error handling should be part of the module function. If one of the following occurs, the module's error handling function contains errors or defects: The description of the error is difficult to understand, the description of the error is insufficient to locate the error, insufficient to determine the cause of the error, the error message displayed is inconsistent with the actual error, and the error condition is handled incorrectly; Error conditions have caused the system to intervene and so on.

Ensure the correctness of the expression and SQL statement, and check the correctness of the syntax and logic of the SQL statement written. The expression should be guaranteed to be free of two semantics, for ambiguous expressions or operator precedence (such as: ", =,", &&, | |, + +,-etc.) can be used to avoid ambiguity of the "()" operator, on the one hand, to ensure that the code is correct and reliable, It can also improve the readability of the code.

VII, check the correctness of the use of constants or global variables, determine the values and values of the constants or global variables used, the data types, and ensure that constants each reference is consistent with its values, values, and types.

Eighth, the specification consistency of the expression definition, the guarantee variable name can be known, and concise but not too long or too short, standardized, easy to remember, it is best to spell. And try to ensure that the same representation is used to represent the same function, do not use different functions with the same representation, and not the same notation to represent different functional meanings.

Ninth, the consistency of procedural style, normative; Code must be able to ensure compliance with enterprise norms, to ensure that all members of the code style consistent, normative, neat. For example, to loop the array, do not take the subscript variable from the bottom to the top of the way (for example: for (I=0;I++;I<10)), a short while using a top-down approach (such as: for (i=10;i--;i>0)), should try to use a unified way, or unified from bottom to top , or unify from top to bottom. It is recommended to use a for loop and a while loop, not to use do{}while loops.

Tenth, whether the mysterious number used in the inspection procedure is used in the expression definition. The mysterious numbers include constants, the size of the array, the position of the character, the transformation factor, and other text-written values that appear in the program. In the program source code, a number with the original form does not provide any indicative information about its own importance or function, and they also cause the program to be difficult to understand and modify. Such mysterious numbers must be represented by the corresponding scalar, and if the number is used throughout the system it is necessary to define it as a global constant, if the mysterious number is used in a class that can be defined as a property of the class (Attribute), if the Mysterious numbers appear only in one method be sure to define them as local variables or constants.

11th, check whether the code can be optimized, the efficiency of the algorithm is the highest. Such as: whether the SQL statement can be optimized, whether you can use 1 SQL statements in place of the functions of multiple SQL statements in the program, whether the loop is necessary, whether the statements in the loop can be extracted out of the loop and so on.

12th, check whether your program is clear and concise and easy to understand. Note: Lengthy programs are not necessarily clear.

13th, check the method internal annotation is complete, clear and concise, whether the correct reflection of the function of the code, the wrong comment is worse than no comment, whether to make redundant comments, for a simple look at the code is not necessary to understand the comment.

14th, check the comment document is complete, the comments on the package, class, property, method function, parameter, return value are correct and easy to understand, whether or not the comment of a parameter is dropped or not, the parameter type is correct, and the qualified value of the parameter is correct. In particular, the comment on the mysterious value of the formal parameter and the return value, such as the type parameter, should indicate 1. What it stands for, 2. What it stands for, 3. What it stands for. For comments that return result sets, you should note that the result set contains those fields and field types, field order, and so on.

　　Dynamic execution Tracking

For unit testing, because the purpose of testing is primarily to test the accuracy of internal functions, a white-box test method should be used to test the internal tracking of each module.

The main steps of dynamic testing:

1, set the data, mainly in order to meet the Unit module operation required input conditions;

2, using the function of the test type, you can design a test class ( Drive module (driver)) to call the test module, and design the module to be called by the test module (stub);

3, compare the actual results with the expected results, the function of the evaluation module to meet the design requirements.

Three, good unit test standard

1, unit testing should be on the most basic function/parameters to verify the correctness of the program

Unit tests should test the most basic elements of a program-such as classes in C++/c#/java-to test the most basic functional points in some systems (these feature points consist of several basic classes). Unit tests to test every method and parameter in the API.

2, Unit test by the program author to write

3, after the test, the machine state win remains unchanged

To ensure that unit tests do not interfere with previous unit test instances, records such as temporary data or files generated during the test should be deleted or separate files should be used for each unit test to prevent mutual interference.

4. Unit tests should produce repeatable, consistent results

Errors that occur during testing should be repeatable.

5. Unit test run/pass/fail independent of other tests, can be considered to construct data to preserve the independence of unit tests

If the other modules are unstable or run relatively time-consuming, and the correctness of this module is not critical, you can artificially construct data to ensure the independence of unit testing.

6. Unit tests should overwrite all code paths

To ensure code coverage, unit tests must test public and private functions/methods.

7. Unit tests should be integrated into the framework of automated tests

8. Unit test must be saved and maintained together with Changping code

If the unit tests are not versioned with the code, then the code is inconsistent with the unit test, and when the test fails, it is not possible to determine whether the error was caused by the program's errors or the unit tests.

Reference:

Talk about unit Test (a): Why do you want to do annoying unit testing? -Purple Feather Blog-Blog Channel-Csdn.net http://blog.csdn.net/happylee6688/article/details/37962283

How to do unit testing _ Software Science Park _ Science and Technology Times _ Sina Network http://tech.sina.com.cn/s/2009-07-20/1529991506.shtml

Code coverage talk-Coderzh-blog Park http://www.cnblogs.com/coderzh/archive/2009/03/29/1424344.html

The Law of Construction-----Unit test