Use of test coverage (rate)

Introduction

People often ask me this question: "We're doing unit testing, so how much is the test coverage going to do?" ”。 And my answer is very simple, "as an indicator of the test coverage is not useful." ”

Martin Fowler, the author of the book, once wrote a blog to discuss the issue, noting that there is no point in testing coverage as a quality goal, and that we should use it as a means of discovering code that has not been tested for coverage.

Http://martinfowler.com/bliki/TestCoverage.html

Brian Marick (one of the first 17 signatories to the Agile Manifesto) also said that as a programmer, I certainly expect my code to have a high test coverage. However, when my manager asked for such an indicator, there was another purpose (performance appraisal?). ）。

I think, high test coverage should be every "serious" to write unit test programmer get the inevitable result, the manager of a result as an indicator to measure, itself is meaningless. If you push the "omnipotent" programmer into a hurry, he will come up with one or two "magic weapons" from the "mystery toolbox" to reach the target "efficiently". I've seen a lot of these "magic weapons", such as not having a "assert" in a unit test, or a unit test that writes a lot of Get and set methods (simple writing) to improve overall coverage, and so on. What's more, the test-full code may not be able to reach 100% coverage, as is the case later in this article.

Then you might ask, "What's the use of the test coverage?" ”。 My answer is still very simple, "test coverage is a learning tool." What do you study? Learn why some code is not covered, and why some code has been tested without fail. Understanding the reasons behind the "why", programmers can do a corresponding improvement and improvement, compared to imagine the effectiveness of the unit test and the code is good or bad, this will be more effective.

Next, I'll show you some of the traditional test coverage methods and a method called Code mutation Testing (Mutation test). You will see what learning points these methods can produce, and where code mutation testing is more valuable than traditional methods. If you're a programmer (I don't tell you whether you're a developer or a tester, that's all the same to me), I hope you'll find some ways to improve your testing and code quality after you've read this article. If you are a manager, whether you are using or trying to use "test coverage" to do metrics, hopefully after you finish this article, you can give up the idea and do something more meaningful (like writing code).

Traditional method of test coverage