Unit Test misunderstanding and dilemmas

Unit Test misunderstanding and dilemmas

The first excuse is that unit tests affect the development progress. They refuse to learn Unit Test-related knowledge (unit tests, code refactoring, and version management are essential for developers ); second, unit testing is "First bitter, then sweet". At the beginning, we set up the environment and introduced additional work, which seems to be "affecting the progress", but in the long run, as the program quality is improved, the Code rework is reduced, the maintenance workload is reduced, and the Project Risk is reduced, the overall win is returned.
Misunderstanding 1: affecting development progress
Once coding is complete, developers are always eager to integrate software so that they can see the actual running effect of the system. This seems to speed up the External table, and activities like unit testing are seen as one of the reasons that affect the progress, delaying the integration testing of the entire system.
In practice, such development steps often lead to the result that the software cannot even run. The further result is that a large amount of time will be spent tracking simple bugs that are contained in independent units. In some cases, these bugs may be trivial and insignificant, but in general, they will lead to a delay in the delivery of software products, and it cannot be ensured that it can run reliably.
In actual work, the Unit Test of the complete plan and the effort to write the actual code are roughly the same. Once these unit tests are completed, many bugs will be corrected and developers can perform more efficient system integration. This is the real progress, so the unit test under the complete plan is more efficient to use time.
Misunderstanding 2: Increase development costs 
If you do not pay attention to the potential consequences of undiscovered bugs in the program. The severity of these consequences can be from the inconvenience caused by a bug to the system crash. Such consequences may often be ignored by software developers, which may damage the reputation of software developers for a long time and negatively impact the future market. On the contrary, a good reputation for a reliable software system will help a software developer gain a future market.
Many research results show that a complete regression test is required no matter when changes are made. Early testing of software products in the life cycle will ensure the best efficiency and quality. The later the bug is discovered, the higher the cost required to modify it. Therefore, from an economic point of view, you should find and modify the bug as early as possible. Unit testing is an early opportunity to seize bugs.
Compared with subsequent tests, unit tests are easier to create, maintain, and refactor. Considering the full cost, unit testing costs are low compared to complex and time-consuming integration tests or unstable software systems.
Misunderstanding 3: I am a programmer and do not need to perform unit tests.
Each development team should have at least one such developer who is very good at programming. The software he develops can always run normally in the first place, so no tests are required. Do you often hear such an excuse? In the real world, everyone makes mistakes. Even if a developer can handle this in a few simple programs, the real software system is very complicated. Real software systems cannot work without extensive tests or bug modification. Encoding is not a one-time process. In the real world, software products must be maintained to respond to changes in functional requirements in a timely manner, and the bugs left behind by the initial development work should be modified. Do you want to rely on those original authors for modification? These senior engineers who have produced untested code will continue to make such code elsewhere. Repeated unit tests can be performed after developers make modifications to avoid unpleasant negative effects.
Misunderstanding 4: testers will detect all bugs
Once the software is ready to run, developers have to face the problem of thoroughly testing each unit while considering the global complexity of the software. This is a very difficult task. When creating a unit call test condition, you must fully consider the various entry parameters when the unit is called. In the software integration stage, the complexity of full testing of Unit functions far exceeds the independent unit testing process.
The final result is that the test will not be able to achieve all the comprehensiveness it should have. Some defects will be missed, and many bugs will be ignored. Let's look at the analogy. Suppose we want to clean up the dust in a computer host. If we haven't split the components (such as the video card and memory) in the host, No matter what tool you use, some dust may be hidden in some corners of the host and cannot be cleared. But from another perspective, if we split each part of the host one by one, the dust in these dead corners will be easily discovered and exposed, and the dust of each part can be easily cleaned up.
Difficulties in Unit Testing

Testing has always attracted much attention in the software development process. testing is not only limited to a stage in software development, but has started to run through the entire software development process. It is widely recognized that if testing can be effectively executed in the development stage, program bugs will be discovered early, and the quality of the programs will be effectively guaranteed, thus reducing the total cost of software development. However, compared with the popularity of the word "test", there are common deviations in unit test cognition, especially some programmers may fall into some misunderstandings, as a result, the test does not play an effective role in the development project where they are located. Next, we will analyze some representative misunderstandings and elaborate on some design ideas behind the test, hoping to serve as a reference.
Misunderstanding and dilemma 1: using system. Out. Print to track and run programs is enough.
This misunderstanding can be said to be a common problem for programmers. out. print ensures the correctness of code writing without writing test cases. They feel that writing cases is a "waste of time ". Using system. Out. Print to output the results, we can use the visual observation of this kind of farming tools for testing, which is not only inefficient, but also prone to errors.
Misunderstanding and dilemma 2: there are too many things that cannot be tested
During coding, there are some codes that seem difficult to test, but they are not unable to be tested. In most cases, it is because the tested code is not designed with regard to testability. Writing a program is not only tightly coupled with some third-party frameworks, but also relies too much on its runtime environment, which shows that the tested code itself is difficult to test.
Misunderstanding and dilemma 3: Test code can be written at will 
When writing the test code, I took a random attitude and did not find out the true intention of the test. Writing the test code is just to cope with the task. First write the program to implement the code, and then write some unit tests. The result is that the test is too simple. It passes a large number of bugs to the system tester only in form and frame.
Misunderstanding and dilemma 4: do not care about the test environment
Manual setup of the test environment and test data make maintenance difficult, which takes a lot of time and seriously affects the efficiency. The "garbage" generated during the test is not cleared and not processed. As a result, tests cannot be repeated, leading to fragile tests. Therefore, we need to maintain the test environment and be a low-carbon and environmentally friendly tester.
Misunderstanding and dilemma 5: high dependence on the test environment

The test environment is highly dependent and does not effectively isolate the test target and its dependent environment. First, the test is not focused; second, the test often fails due to the impact of the dependent environment; third, the dependency environment is too heavy to reduce the test efficiency (such as relying on databases or network resources, such as email systems and web services ).

 -- This text is excerpted from spring 3.x enterprise application development practices

Book details: http://blog.csdn.net/broadview2006/article/details/7326175