The benefits of unit testing in Android APP testing

   
Many developers have a habit and are often reluctant to write a simple unit test program to verify their code. I have always been very confident in my own program, or have a fluke mentality and throw it directly to the test group for testing every time it passes. However, every time the BUG of the test group is submitted, they will find that there are still many unexpected loopholes in their program. But every time I modify the bug, I still take a fluke and think that there will be no bugs this time. Then commit again confidently and lose again. Because this is repeated several times.

The time the developer spends looking for bugs and fixing them adds up to more time than he spends developing this module. Although the project manager has reserved time for bug fixes and unit tests. But developers habitually think the task is done after they have written the code. Then, when the problem came out and the bug was fixed many times and still couldn't be fixed, I said to the project manager, "I encountered an unexpected problem and may have to postpone the release of my code." If the project cannot be postponed, painful overtime cannot be avoided.

Why are there so many BUG developers did not find it. In fact, developers are people, not machines. People can not escape from doing wrong. BUG is unavoidable, but it is basically impossible to know which piece of code caused the bug before every time a bug is fixed. It may take you an hour or a day to locate a bug each time, depending on your level.

But if each of your core programs has unit test code, you won't need to rely on your experience to judge or guess which program the bug is caused by, you just need to run your unit test method. BUG can be easily located by simply judging the results of the test method. So on the surface, writing test code for each unit program may seem like an increase in workload, but in fact, these codes not only weave a protective net for you, but also help you quickly locate errors so that you can greatly reduce Time to fix bugs. And this is also beneficial to your health, you will not be in pain because you can't find bugs, and you will not have to work overtime without sleep or food. And the progress of the project will be kept under control.

In fact, unit testing can not only ensure the progress of the project but also optimize your design. Some developers will say that writing unit test code is too laborious, more troublesome than writing business code. However, if developers are forced to write unit test code, the only way for smart and 'lazy' developers to write test code more conveniently in the future is to optimize the design and design the business code as much as possible. Easy-to-test code. Slowly, developers will find that the coupling degree of the programs they design is getting lower and lower, and the input and output of each unit program, business content and abnormal situations will be as simple as possible. In the end, I found that my programming habits and design ability became more and more sophisticated.

In fact, easy-to-test code can basically be equated with well-designed code. Because a unit test case is actually the earliest user of a unit. Ease of use obviously means good design.

Well-designed projects have always focused on code reuse. To achieve code reuse, we must first ensure that the reused unit program must be a very good program, in addition to good design, but also detailed documentation. The most important thing is actually to unit test the code.

The unit test code can also be tested based on real data in the production environment through the simple transaction rollback function without worrying about unnecessary data. Using such test code, we can check whether the release just now is successful after releasing the program.

Many studies have shown that the later a bug is discovered, the more expensive it will be to fix it, so from a cost perspective, bugs should be found and fixed as early as possible. Maybe someone will object? The programmers found all the bugs, what did the test team do? In fact, the test group is conducting integrated APP testing , which cannot comprehensively take into account the various input parameters used when each unit is called. Just like a car, testing every part is a must. Testing an assembled car is no substitute for individual testing of each part. Perhaps testing the assembled car could reveal problems with certain components. But at this time, if the problem is found, the car needs to be disassembled and replaced with parts. The resulting cost can be imagined.