A preliminary understanding of the value of code coverage

Regarding code coverage, I have only vaguely heard about it in my previous 6 years of work experience. In the previous organization, I never paid attention to this indicator, but I used NUnit for unit testing for a period of time, mainly to test whether some key classes and key methods are normal. The impression of code coverage has really stayed at the level of hearing. . Sweat one!

Some time ago, someone mentioned code coverage in the discussion about automatic testing, which aroused my curiosity, what exactly is code coverage? And most importantly, what's the value in terms of testing work? Spent a little time today to check it out and got a preliminary understanding. It can be roughly summarized as follows:

1. Basic Concepts

   Code coverage is one of the unit testing activity tasks;

   coverage is divided into statement coverage (so-called line coverage) and branch coverage.

two. The analysis of the value

   code coverage can judge the quality of the code to a certain extent. Generally, the probability of errors in the code with high coverage will be relatively low. But high coverage just means that a lot of code is executed, it doesn't mean that the code is executed well. Therefore, it seems that the coverage test results do not help me accurately evaluate the quality of the code. So why do we do coverage testing? How can it bring us value?

   1. Assess code quality early.

For example, in the process of development, regularly check the code coverage of the entire project, and monitoring the coverage report can help the development team quickly find out the growing code without corresponding tests. For example, running a coverage report at the beginning of the week shows that a critical package in the project has 70% coverage. If after a few days, the coverage drops to 60%, then you can infer that the package has increased lines of code, but no corresponding tests have been written for the new code (or the newly added tests do not effectively cover the new code). Being able to monitor how things are going is definitely a good thing. Reviewing reports on a regular basis makes it easier to set goals (such as getting coverage, percentage of test cases maintaining lines of code, etc.) and monitoring how things are developing. If you find that your tests are not being written as expected, you can take some action ahead of time, such as training, mentoring, or helping the developers.

   2. Provide intelligence on functional testing concerns

Assuming coverage reports are very effective in pointing out sections of code that have not been adequately tested, QA can use this data to rate areas of concern related to functional testing that can be more targeted for enhancements Tests in these areas, because the areas not covered by the test code, should have a relatively higher chance of error.

   3. Estimate the time required to modify existing code

　　For a development team, writing test cases against the code naturally increases collective confidence. Tested code is easier to refactor, maintain, and enhance than code without corresponding test cases. Test cases can also serve as documentation for the insider because they hint at how the code works in the test job. On the other hand, code that has not been tested accordingly is more difficult to understand and to modify safely. Therefore, knowing whether code has been tested, and seeing actual test coverage numbers, allows developers and managers to more accurately predict how long it will take to modify existing code.

   -----

   Of course, this kind of understanding is still relatively shallow. I think in addition to the above three points in practical applications, there is also a very important work to improve the quality of the test code to better reflect the code coverage. value.


Original source: http://www.51testing.com/?uid-101957-action-viewspace-itemid-70695