C/C ++ unit testing theory (6)

2.1 testability (2)

 

 

 

Next we will discuss the key issue: overwrite the input. What is a function input? The input includes two aspects: external input and internal input. External Input is easy to understand, that is, the input that can be set outside the function, including parameters, global variables, and member variables.

 

The key is internal input. Because few documents discuss internal input, for many people, internal input may be a strange word. Let's first look at what internal input is. How does a function handle the data obtained by calling the underlying function? Like parameters, it is also classified. Therefore, classification detection is also required during testing, which is no different from the parameter. This is the internal input.

 

 

What are the internal input situations? There are six types: Natural Input, uncontrollable, distorted, difficult to initialize, static input, and interrupted input.

Natural Input
 

 

Natural input is the actual code that calls the underlying function to obtain the natural computing result. Underlying functions must exist, be controllable, and correct. For natural input, there is no need to do anything during testing. In order to check whether the program makes proper judgment and processing on the various possible outputs of the underlying functions, the underlying functions need to output appropriate data, this requires indirect control of the output of underlying functions by setting appropriate parameters and other data. Sometimes, this work is very difficult, and it is difficult to initialize. I will introduce it later.

 

Uncontrollable

 

 

 

The underlying function still calls the actual code, but the output of the underlying function does not meet the test requirements. In this example, the underlying function is used to obtain the ambient temperature. We need to check whether the program has properly processed various ambient temperatures, but the actual ambient temperature cannot change significantly in real time, this is uncontrollable. Uncontrollable unit tests are quite common. For example, the underlying function returns a random number, which is also uncontrollable. The underlying function is used to connect to the network and may not be able to control its various States, these are uncontrollable.

 

Distortion
 

 

 

Underlying functions call a pile of code. Of course, the pile of code cannot implement the functions of the original code, which is distorted. This example is the same function that cannot be controlled. The difference is that the underlying function calls the pile code. The average pile Code does nothing, and the return value of the underlying function is always 0, the test fails if no ambient temperature is output. Distortion is caused by piling and is the inevitable result of piling. Can we solve the distortion by modifying the pile code? Sometimes it works. Sometimes it doesn't work. We will introduce it further later.
We discussed distortion just now.

Difficult to initialize

 

 

When talking about natural input, we have discussed that in order to make the underlying function generate the required test output, we need to set the appropriate external input, that is, to initialize the underlying function by setting the external input, most of the time, this work is very difficult. For example, to make the Circle area equal to 100.00 square meters, what is the radius? Another example is that to make a ing table return true results when searching for an object, you need to create the object and add it to the table in advance. It is a simple output, but it needs to be initialized in a complicated way. In actual work, it is more difficult than these examples. These are difficult to initialize.

 

Static Input

 

 

 

Local static variables are quite common in C code, especially embedded code. Local static variables are the same as global variables. Generally, different initial values need to be set for each case. But it cannot be accessed from the outside, which is also an internal input.

 

Interrupt input
 

 

Interrupt input is common in Embedded projects. If the program runs under test, the system may interrupt, interrupt may call some code, and may cause modifications to global variables. In addition, such modifications may affect the functional logic of the program, this is also an internal input, which must be considered during testing.

 

We have introduced six internal input cases. Except for natural input, the other five cases must be solved.

 

What if the problem of testability is solved? As mentioned above, it is unrealistic to try to improve the development process to solve testability. Through a specific analysis of testability problems, I think you know that no matter how you improve the development process, you can only solve a small number of problems. For example, most internal input problems are caused by insufficient code. We can only solve this problem by improving the testing technology and using appropriate tools.