Why do you have annoying unit testing?
IPL
(This article is reproduced from Software Engineering Expert Network
Www.21cmm.com)
Summary This article mainly explains such a question: Why do you want annoying unit testing? Developers who have just been exposed to fully testing are often encountered. We will use the "anti-call argument" method to answer this question, first propose some universal arguments against unit testing, and then we will prove that these arguments can't stand their feet. Those disclosed articles and data fully confirm the effectiveness of unit testing. IPL is an independent software development agency, founded in 1979, based on Bath. IPL adopted ISO9001 certification in 1988 and passed Tickit certification in 1991. IPL development and provides software verification products such as Adatest and Cantata. Adatest and Cantata development have followed these standards. Introduction In an attempt to make new products and business development processes, the quality and reliability of software are often seen as weak links. In the last decade, as more and more people use design methodology and using Case tools, software quality and reliability in the development process, it is more and more attention. Most software designers have accepted this training and have achieved many experiences in the use of these formal software design methods. But unfortunately, software testing did not get the same attention. Many development activities using these software design methods have not controlled software quality and reliability. The rebounded BUG that modifies the initial software development activities should generally take up to 50% in software maintenance costs, which is not normal, and these bugs should be excluded during a valid software test. This article mainly explains such a question: Why do you have annoying unit testing? Developers who have just been exposed to fully testing are often encountered. We will use the "anti-call argument" method to answer this question, first list some of the universal arguments for the unit test, and then we will prove that these arguments are unfair. Those disclosed articles and data fully confirm the effectiveness of unit testing. What is the unit test unit testing is the lowest level test activity to be performed during the software development. In unit test activity, the software's independent unit will test in the case of isolating other parts of the program. In a conventional structured programming language, such as c, the unit to be tested is generally a function or sub-process. In the object-oriented language like C , the basic unit to be tested is class. For the ADA language, developers can choose to perform unit testing at the independent process and function or at the level of the ADA package. The principle of the unit test is also expanded to the development of the fourth generation language (4GL) where the basic unit is typically divided into a menu or display interface. Unit tests are not only used as a non-wrong coding a auxiliary means in a disposable development process, and the unit test must be repeatable, both in the process of software modification, or transplanted to a new operating environment. Therefore, all tests must be maintained in the life cycle of the entire software system. Other development activities that are often associated with unit testing include code reading (Static Analysis) and dynamic analysis (Dynami Analysis). Static analysis is to study the source code of the software, find errors or collect some metric data, and do not need to compile and execute the code. Dynamic analysis is to provide information on tracking, time analysis, and test coverage by observing the operation of the software. Some popular misunderstandings have been clearly clear after the unit test, we can conduct "anti-call argument". In the following sections, we list some of the general arguments against unit tests. Then use a sufficient reason to prove that these arguments are not enough. It wasted too much time once the code was completed, developers always urgently hoped to integrate software, so they can see the actual system began to start working.
This seems to be an obvious progress in the appearance, and the event of the unit test may be seen as an obstacle to the road to this stage, postponed this true interesting of the entire system. Work started. In this development step, the progress in the true sense is replaced by progress on the appearance. The possibility that the system can work is very small, and more cases are full of a wide range of bugs. In practice, such a development step often results in such a result: software can't run. Further results are a large amount of time will cost to track the simple bugs contained in the independent unit. In individual cases, these bugs may be trivial and insignificant, but in general, they will lead to software. Integrate additional work during integration, and cannot be securely run when this system is put into use. In practice, the complete planned unit testing and the energy cost of writing the actual code are substantially the same. Once these unit tests are completed, many bugs will be corrected, and when confident that their hand has a stable and reliable part, developers can make more efficient system integration. This is a realistic progress, so the unit test under the full plan is a more efficient use of time. The uncontrolled and scattered work of debugging people will only take more time and have achieved few benefits. Support tools such as Adatest and Cantata allow unit testing easier and effective. But this is not necessary, unit testing is a very meaningful activity even if there is no tool support. It just proves what this code did this is the universal complaints proposed by developers who do not first write a detailed specification for each unit and directly jump to the coding phase, when the coding is completed and facing the code test task. When they read these code and identified what they did actually did, put their tests based on the code that has been written. Of course, they can't prove anything. All of these tests can indicate that the compiler works fine. Yes, they may be able to catch (hope to be able to) rare compiler bug, but they can do just this. If they first write a detailed specification, the test can be based on a specification. The code can be tested for it for its specifications instead of testing themselves. Such tests can still grasp the compiler's bug, and you can find more encoding errors, even in some specification. A good specification describes the quality of the test, so the final conclusion is that high quality tests require high quality specifications. This will happen in practice: A developer should face only the code to give only the unit's code and there is no specification, such a task that does not expect this. How do you do more gains, not just the bugs of the compiler? The first step is to understand what this unit has to do, - not what it actually did. A more effective way is to put out a profile specification. The main input condition of this process is to read those program code and annotations, mainly for this unit, and call it and the related code it is called. Drawing flow chart is very helpful, you can use some kind of tool with handles. The Reading of this profile specification can be organized to ensure that there is no basic error on this unit, and this minimum degree of code is deeply described, you can use it to design the unit test. I am a great programmer, can I not perform a unit test? At least one such developer in each development organization, he is very good at programming, and the software they develop will always run in the first time, so there is no need to test. Do you often hear such an excuse? In the real world, everyone will make mistakes. Even if a developer can hold this attitude in some simple programs to deal with some simple programs. But the real software system is very complicated. The real software system can not be hoped that there is no extensive test and bug modification process.
The encoding is not a process that can pass one time. In the real world, software products must be maintained to react with changes in operational demand, and to modify the BUG left by the initial development work. Do you want to rely on the original author to modify? These senior experts who have made these unparalleled original code will continue to make such code elsewhere. A repetitive unit testing of developers can avoid being uncomfortable. In any case, the integrated test will seize all bugs we have explained this problem from one side in the previous discussion. The reason for this argument is that the larger code integration is, the higher the complexity. If the unit of the software does not test in advance, the developer is likely to spend a lot of time just to make the software to run, and any actual test plan cannot be executed. Once the software can run, the developers have to face such problems: a comprehensive test of each unit is considered in consideration of the global complexity of the software. This is a very difficult thing, even when creating a unit called test condition, it is necessary to consider the various entrance parameters of the unit's call. In the software integration phase, the complexity of the unit function is fully tested far more than the independent unit testing process. The final result is that the test will not be able to reach the totality of it. Some defects will be omitted, and many bugs will be ignored. Let us compare, suppose we want to clean a food processing machine that has been fully equipped! No matter how much water and cleaners you spray, some food small pieces will also stick to the dead position of the machine, only any of them rot and wait I will find a way later. But we think about it, if this machine is disassembled, these dead ends may not exist or easier to come into contact, and each part can be cleaned without effort. Its cost-effectiveness is not a specific development organization or software application system's test level depends on the level of attention to the potential consequences of unrecognized bugs. The severity of this consequence can be from a small inconvenience caused by a bug that occurs multiple cranes. This consequence may often be ignored by the developer of the software (but the user will not be like this), this situation will overhaul the development organization of the BUG-based software to future markets, and will lead to future markets A negative impact. Conversely, a good reputation of a reliable software system will help a development organization to obtain future markets. Many research results show that no matter when making modifications, it is necessary to conduct a complete regression test, and test the software products as early as the life cycle will make efficiency and quality best guarantee. The passenger discovered, the higher the cost of modifying it, so it should look up and modify the bug as early as possible from an economic point of view. The unit test is an opportunity to seize the bug earlier during the modification of the cost. In compared with the test, the creation of unit testing is simpler, more maintenance, and more convenient to repeat. Considering the cost of the whole process, the cost required for unit testing is low compared to those complex and lasting integrated tests, or unstable software systems. Some charts These graphs are taken from << Practical Software Metrics >> (CAPERS JONES, McGraw-Hill 1991), which lists the time spent on preparation test, execution test, and modification defects (based on a function point), these data The cost efficiency of the display unit test is approximately three times the two-fold system test of the integrated test (see bar chart). (Field Test means that all test activities made in a certain field will not indicate that the developer should not perform the test activity in a certain field, this test activity is still a must . Its true meaning is as early as possible to exclude as many bugs as possible to reduce the cost of post-phase tests. Some of the other charts show up to 50% of the maintenance workload is spent on those who always have bugs.
