C/C ++ unit testing theory (4)

Reason for persistent persistence of unit testing and Its Solution

 

In the previous article "unit test benefits", some netizens commented: "The benefits of unit test are basically known to everyone, so it is hard to stick to it !". This comment seriously reminds me that "hard to stick" is also a general situation. If you can't stick to it, everything will be useless. Therefore, I will insert an additional article here to discuss the reasons and solutions for the persistent persistence of unit testing. I hope you will discuss it and find a way to make unit testing easier.

 

I used to focus on how to do it, how to do it quickly, and how to do it well. I have hardly considered long-term persistence independently. The reason is probably: For myself, this is not a problem, I have been doing unit tests for ten years. In the past ten years, I have been writing and testing code. So what causes me to perform unit tests for a long time?

 

This decade has been divided into two phases: the next six years specialized in unit testing technology and tools, and some outsourcing projects in the previous four years. If unit testing has become my major and I want to do it on my own, I cannot explain why I persisted in the past four years. It was the first four years of unit testing that led me to focus on the unit testing field.

 

Looking back on the course of unit testing for ten years, I found that I never insisted on it. I am not a rational and persevering person. I prefer to think about it. I can do the same thing without interruption for ten years. It should be because something has attracted me, it makes me want to do it naturally, instead of forcing myself to do it.

 

One thing: If you need rational power to barely stick to it, after a long time, enthusiasm will fade, inertia will gradually gain the upper hand, and slowly may give up, such as healthy eating habits. Some things may not be good from the rational aspect, but they are easy to indulge in, such as playing online games. Why? The latter has immediate and emotional appeal, forming a "Temptation", which naturally makes people like to do it for a long time. The emotional appeal at the moment can often easily defeat the later and more rational benefits.

 

I think it is precisely because of some "immediate and emotional attractiveness" of unit testing that it forms a "Temptation" that makes me happy to do it, rather than barely doing it. So what is "temptation? Why isn't unit testing a common "Temptation? What is the difference between my unit test and general unit test?

 

In retrospect, the difference is true. From the very beginning, all the tools I used were developed by myself. At that time, because we could not find satisfactory tools, we developed our own functions that we needed most.

 

The first version of this tool is mainly used to generate test code. After modification, a test case is formed.

 

The second version adds the automatic generation of Use Cases function, which is disappointing after use, because the tool cannot automatically understand the code function, and the automatic generation of use cases is almost useless, it is better to directly write the use case when selecting and modifying a bunch of generated use cases.

 

The third version adds the function to describe program behavior, that is, to display the code executed and output of the tested program under certain inputs, that is, the program behavior is visible. This function is too easy to use. You can write a few lines of code to see what the program is doing. The programming efficiency is improved, but the work intensity is reduced. Later, we call this development mode "visual programming" and "visible", which means that the program behavior is visible.

 

The biggest difference between my tools and general testing tools is that it supports visual programming. The biggest difference between my unit testing and general unit testing lies in visual programming. In a general unit test, the focus is on whether the test is successful. After I write a few lines of code and run the test, I first see what output data is generated, in addition to common parameters, member variables, and global variables, the intermediate results also include the values of important variables or expressions at a specified position within the function. If the output data is different from what I expected, let's look at the code executed, so that we can easily find out the error and correct it before continuing to write. After the code is written, check which tests fail and compare the input and output with the corresponding executed code to find out the cause of the error. debugging is rarely used, my ability to use the debugger has been severely degraded.

 

Now I want to think about it. The "instant and emotional attraction" of "Temptation" I am willing to perform unit tests for a long time lies in visual programming. For example, if you are writing a complex function, and the program behavior is invisible, I will always imagine what the Code has already been written will do, and I have no idea whether it is right or not, of course, it's hard and tired, and debugging is the most annoying. I remember that when I haven't done a unit test, sometimes I'm still in the middle of the night to find a small bug, it seems that everything is correct, that is, the result is wrong, and you can't wait to drop the computer. If you write code, you can check what the program has done and it feels pretty cool. This is "immediate and emotional appeal ". Other benefits of unit testing are more rational. I generally don't think about these benefits. However, if I do unit testing, these benefits won't run.

 

Visual Programming emphasizes development, rather than testing. It does not need to change programming habits or interfere with thinking. Programmers are afraid of being disturbed. If the tool is automated and can generate test code or something, visual programming does not require any additional work. When writing code, you must be clear about the functions of the Code, the function is generally based on the input, the output, and the test case, in addition, you can have a clearer understanding of the functions to be implemented by the program.

 

As long as a unit test is performed, the data will certainly exist under what inputs the program will execute and what code will generate and what outputs it will produce. The problem is whether or not it can be used. I think it is a pity that most unit testing theories and tools ignore this precious resource.

 

As to whether visual programming can solve the persistent problem of unit testing in general, I cannot draw a conclusion. Welcome to discuss it. I have prepared a video to demonstrate the process of visual programming. Unfortunately, the resource library uploaded to csdn has been deleted and I don't know why. If you are interested in watching this video and experiencing visual programming, send me a csdn text message.

 

If you feel that visual programming is really good and it is expected to solve the problem that is difficult to stick to, it is expected to solve the problem, because no matter what tool you are using, as long as you do a unit test, then, the data that can make the program behavior visible must exist. You just need to find a way to capture them. The common capture method is plug-in, which inserts some code into the tested code to output data and monitor the code execution status.

 

Of course, to make the unit test really smooth, we must also eliminate the main obstacles that will "get stuck" in the test, solve the testability problem, and have a good test effect and make the test as efficient as possible, will discuss these issues.