Test concept
Deng Hui
So far, the test is still a recognized means of the most effective means of inspection procedures. Detailed tests can greatly reduce the defect rate of the program. Although the defect rate is currently a recognized inspection process quality, it is just a result, and an indicator value to be satisfied is to pay a certain price.
Worse, there are many projects that only put the attention on this defect rate and coverage results, they have written a very detailed test case document, and then write corresponding test code according to this use case document. carry out testing. This practice may work well in the case of software demand, but the demand continues to change this, everyone is unwilling to see the reality that cannot be avoided, bringing a huge blow to this test method. The increase in functions, modifications and bug fixes inevitably lead to changes in the program structure, and this test case document and test code that only pays attention to coverage will inevitably depend on the structure of the program. The results are naturally difficult to imagine. They not only go to change the program structure, but also have to change the test code, even when the required program features have not changed. What is even worse is, they have to change the test case document to keep their and test sample code and the code to test. Otherwise, this document will become out, there is nothing but nothing to exchange, but it will become dangerous.
Why do this result? Do you say that they pay attention to the coverage? The coverage itself has no errors, but because they cut the coverage, defect rate, and software other characteristics (where the most important one is encapsulation), this cut will inevitably bring high test costs. A code with a bad change rate package, it is likely to achieve high test coverage, regardless of the cost you pay. This is the punishment of software entropy.
So we must want to reduce the cost of the test and make effective testing under the premise of ensuring coverage and defect rate. We must put the focus on the other inner quality of the software. I think the most important indicators are: Captive level, change rate isolation level, dependency processing level, and whether there is an onCe and ONLY ONCE principle. These indicators will greatly enhance software flexibility and changeable, and will greatly improve the testability of the software itself, directly reducing the cost and quality of the test.
In fact, in order to be able to adapt to the needs of the requirements mentioned earlier, many explorers have proposed some technologies that help to achieve the quality indicators mentioned above, such as: oo, AOP, IOC, and language dynamics, etc.) Many of the process methods that can be followed when software development is proposed, with an iterative method being a method of universally recognized. Similarly, the skills we have mastered directly determines the results of the process usage we want to implement. A team that does not master OO skills is likely to be severely hit when the iterative method is implemented. Because of the test, they lack sufficient skills needed to keep the software "soft".
Said so much, I mainly want to express it, I hope that we should not talk to tests isolated, but to recognize the relationship between developers themselves and test validity. Increasing the fundamental way to improve test validity (including effectiveness to improve process) is to improve the skills of developers. This skill is not the ability of the code to write code, but their recognition ability for good code and bad code. This will be very economically highly improved from the root of the software quality and develop productivity. When we choose a process method and practice, we have to have targeted selections of some of the people's current development skills based on their own team.
So how should the team start? I think TDD (Test-Driven Development) is a good starting point. Through TDD practice, we can improve our analysis, design capabilities, improve programming style (note is not programming specifications), improve our fast iteration and rhythm Control capabilities can improve our identification and reconstruction capabilities for Code Smell, most important is to improve our understanding and rapid verification capabilities of our needs (that is, our ability to do correct things). These capabilities are necessary to implement tests and iterations more effectively. There are many practices in agile methods, but TDD is the only practice of being widely recognized. Recently, MSDN TV interviewed the author Steve McConnell for "Code Complete", asked if the author would revise the "Rapid Development" book, change the content, Steve McConnell, so far What will be changed is to increase the best practices into TDD. TDD is a big topic, I will not go any more here. But one thing must remember: tdd is not about testing. As a result of the test kit, it is just a by-product. More detailed information can refer to Kent Beck's "Test-Driven Development" and Robert Martin "Agile Software Development". In addition, there is more detailed information on testing knowledge, you can refer to I "Software Test Cognition in IBM DeveloperWorks last year".
Talking about TDD, I can't help but remember the problem of the need to explore the necessaryity of the coverage before two days. A friend finally held an example, Kent Beck said that the results of TDD implementation in the "Test-Driven Development" book, inevitably 100% (or close) test coverage. In fact, when talking about TDD, it is generally not discussed, and Mr. Beck is only comparable to the traditional understanding. Why do you easily reach a 100% coverage after implementing TDD? The reason is this: TDD makes you pay attention to the responsibilities test. When you do TDD, you have to constantly refactor your code to make it good, you have to continue to eliminate the taste in your code. The final result, you get a single responsibility, no duplicate, interface orthogonal, compact, method short and excluding (or few) branches (modules). And you are based on responsibilities, it is difficult to think about 100%. Yes, good code will inevitably bring enough high enough test coverage.
Below, I want to talk about some suggestions for testing promotion in the company, for reference only:
l I oppose opinions in terms of test case documentation. I think the test case code itself is a document that can be run, and will remain synchronized with the actual code, and most intuitive, clear and no ambiguity. Of course, the premise is that we must abide by TDD discipline. If you really need a written document (this situation rarely occurs), we can generate through the Self-Documented code, such as using Javadoc tools in Java. Of course, some high-level illustrative documents are except.
l You can use the coverage as an indicator, but it should not be used as a unique indicator. It should be counted in other more latitude metrics. The most important thing is to pay attention to the cost of high coverage, if the price is high, it is definitely the quality of the code itself is not high.
