Summary
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 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 the 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 increasingly valued. 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 unit test
The unit test is the lowest level test activity to be performed during the software development process. In the 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
After clearing what is 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 waste too much time
Once the coding is completed, developers always want to integrate software, so they can see the actual system starts to start. 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's just to prove what these code did.
This is a universal complaint that the 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, they read these code and find What did it actually do, put their test work based on the code already 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 catch all the bugs.
We have been explained 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 is not high
A specific development organization or software application system depends on the level of attention to the potential consequences of those undispecked 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 chart
These charts are taken from the << Practical Software Measure >> (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 display units The cost efficiency of the test is approximately three times the two-fold system test of the integrated test (see bar chart).
(Field Test means all test activities made in a certain field after the software is put into use.
This chart does not mean that developers should not perform post-stage test activities, this test activity is still necessary. 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. If these bugs are excluded during the development phase, these workloads can save. This potential for 50% software maintenance costs will have a significant impact on 50% software maintenance costs than the initial development costs.
in conclusion
Experience shows that a unit test method that will find a lot of bugs in some stages of software development, and the cost of modifying them is also low. In the later stage of software development, BUG discovery and modification will become more difficult and consume a lot of time and development costs. No matter how often makes a complete regression test, testing the software products as early as possible, and the efficiency and quality will be optimized. In the case of a test-tested unit, the system integration process will greatly simplify. Developers can focus on interaction between units and global functions, rather than falling into units full of BUGs.
The key to maximizing testing work is to select the correct test strategy, which contains the concept of a complete unit test, as well as good management of the test process, and tools suitable as adatest and cantata To support the test process. These activities can produce such a result: more stable software is obtained in the event of a lower development cost. Further benefits are simplified maintenance processes and reduced the cost of life cycle. Effective unit testing is part of the implementation of global quality culture, and this quality culture will bring unlimited business opportunities for software developers.
