According to Wikipedia, unit testing is also called module testing. It is a test work for correctness verification of program units. A program unit is the smallest testable component of an application. In procedural programming, a unit is a single program, function, procedure, etc. For object-oriented programming, the smallest unit is a method.
Generally speaking, programmers will perform at least one unit test every time they modify a program. During the process of writing a program, multiple unit tests may be performed to confirm that the program meets the requirements.
So why do unit tests?
Let’s first take a look at the common self-test methods for Android programmers:
After implementing a certain function, execute the entire application on the mobile phone, and then operate the application on the mobile phone. After multiple clicks on the interface, enter the scene where the function is used, and then test the function. Usually only the main path of function execution is tested. That is to say, if the function has multiple branch structures (if-else), then only one main path will be tested during self-test, and other branch structures will be handed over to testers for manual testing.
So what's the problem with doing this?
If you can ensure that there are no problems every time you implement a function, then the above process does not seem to be a big problem. But in fact, every time we implement a certain function, no one can guarantee that after writing the function implementation code, we will ensure that it has no problems at all. Who can say that, I can only hehe. In fact, every time we implement the function, there will be more or less problems. We need to modify the code repeatedly to test whether our logic is normal. According to the above process, after we modify the code, we need to compile and generate an apk, connect it to the mobile phone, and It usually takes 2 minutes to install the application on the mobile phone, and then operate the mobile phone to enter the functional scene, test the functional scene, and observe the results, which usually takes 1 minute. So every time we finish writing the code, it takes 3 minutes to verify. If we modify it 5 times, it takes 2 minutes to locate the problem and modify the logic each time. Then it takes 5*(2+3)= to ensure that the main logic of the function is OK. 25 minutes, of which 60% (15 minutes) is used to verify the problem and 40% (10 minutes) is used to actually solve the problem.
From this perspective, this self-test method is very inefficient. It also requires programmers to constantly switch between the programming IDE on the computer and the application on the mobile phone, and also perform repeated operations on the mobile phone. For programmers, In fact, it is a very painful thing and easy to operate incorrectly. Sometimes it takes a long time to wait for the phone to connect to the computer, especially when installing the driver. Even the adb conflict causes the connection to have to wait for a long time. Sometimes the company requires that the development phone be returned and replaced with a new development machine. , using a new development mobile phone will be very unfamiliar, and it takes half a day to turn on the debugging mode on the mobile phone. These are things that greatly delay work efficiency and make programmers very painful.
In addition, this kind of test usually only tests the main process of function execution, and there are many branch processes that will not be executed. When it is handed over to testers for execution, because testers usually do black box testing, they do not know much about the internal logic. , it is easy to miss the tests of certain branches, and the preparation conditions of these branches are also difficult for testers to prepare, so even if they are known, the tests of certain branches will be ignored. If there are problems with these branches, they will be exposed on the user side. Therefore, this kind of test cannot guarantee that the non-main branch of the function can also execute normally.
In addition, even if this testing method makes the initial implementation of the function OK, its logic or the logic it depends on will be continuously modified during subsequent iterations. At this time, problems arise, because after we modify the logic it depends on, and Test students will no longer be allowed to test this feature. We may have all encountered this scenario. After we fixed a bug, after a while, we fixed another bug. This bug was fixed, but the bug that was modified a while ago reappeared. Why is this? Because when we modify a bug, we usually focus on this one bug. When we modify the logic, we only focus on correcting the logic that caused the problem. However, after adjusting the logic that caused the problem, it may lead to other problems. . For example, if function A calls function C, hoping it returns "Hello", function B calls function C, hoping it returns "Hello2", one day function A wants function C to return "HelloC", so the logic of function C is modified, As a result, function A does indeed return "HelloC" when calling function C, but function B also returns "HelloC" when calling function C. Then there is a problem. We may not notice this problem and just release the version directly. When it comes to the user side, a large number of users will complain. If we test all the bugs and functions every time we release a version, it will take a very long time and seriously delay the project progress.
Let’s go back to the original question, why do we need to do unit testing? From the above perspectives, we have seen the problems with the usual self-test methods. Let’s see how unit testing can solve these problems:
Inefficiency problem
When using JUnit's unit test, you can verify the correctness of the code logic without using the mobile phone, and you do not need to operate on the mobile phone. After executing the test case, it will directly output whether the test result is normal. If it is normal, the execution result will be green, and if it fails, it will be red. The execution results of the color can shorten the verification operation time to within 30 seconds. Of course we need to spend some time writing test cases, but this is just a one-time job.
Finally, I would like to thank everyone who reads my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it directly:
These materials should be the most comprehensive and complete preparation warehouse for [ software testing ] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can also help you! Anyone in need Partners can click on the small card below to receive it