Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to use coverage indicators to measure the quality of the test suite Test Suite. Many people may not know much about it. In order to make you understand better, the editor has summarized the following for you. I hope you can get something from this article.

Use coverage to measure the quality of the test suite Test Suite

There are two popular ways to measure test coverage:

Code coverage

Branch coverage

The coverage metric shows how much code a test suite (Test Suite) will execute, ranging from 0 to 100%.

In addition to the above two methods, there are many other measures. They are all used to evaluate the quality of a test suite.

People usually think that the higher the coverage, the better. Unfortunately, this is not that simple. Coverage metrics do provide very valuable feedback, but they do not effectively assess the quality of test suites. This is the same as the ability of code to perform unit tests: the coverage metric is a very good negative indicator (it can assess whether the test suite is poor), but it cannot assess whether the test suite is good or not.

Code coverage measurement

The first and most used measure is code coverage (code coverage, also known as test coverage test coverage). Its formula is as follows:

For example:

You can see that the number of valid lines of code becomes 3 lines (8, 9, 10), and they are all green, indicating that they are all overwritten. You can also see from the tool that the coverage has increased to 100%:

To use replication coverage, you have to find a way to sum all the possible branches in the code, and then check how many branches the test has gone.

Example:

As in the previous example, there are two cases in the IsStringLong method, that is, two branches. The test will only run a situation that is less than or equal to 5, so the branch coverage is 50%:

And we only considered one of them. So you may encounter a lot of extreme situations, and you won't be able to see if the test takes everything into account.

This is not to say that coverage metrics should take into account the code paths of external libraries (they should not), but that you can't count on these metrics to assess the quality of unit tests. Coverage metrics cannot tell whether your tests are exhaustive or whether there are enough tests.

Specific coverage figures

Take coverage measurement as an indicator, not a goal.

Like a sick patient in hospital, a high body temperature may indicate a fever, which is a useful observation. However, hospitals should not treat patients by all means to lower their body temperature as the goal of treatment.

In general, it is good if the test coverage of a certain part of the core of the system is high, but it is not good if high coverage is the goal.

Personally, I don't think it's good to have coverage below 60%, which means there's a lot of code untested. But higher coverage figures don't mean anything. So measuring coverage is only the first step in verifying the quality of the test suite.

After reading the above, do you have any further understanding of how to use coverage metrics to measure the quality of the test suite Test Suite? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.