The relationship between Sonarcube coverage and co

标签：eal   some   you   tst   ber   either   something   throw   java   

复制代码
public class DltApiHttpRequestRetryHandler implements HttpRequestRetryHandler {
private PropertiesConfiguration config = BusinessConfigUtil.getConfiguration();
private Logger logger = LoggerFactory.getLogger(getClass());

@Override
public boolean retryRequest(IOException exception, int executionCount, HttpContext context) {
    logger.warn("(Could not execute request. Execution count) : {}.\n{}", executionCount, exception.getMessage());
    if (executionCount >= Integer.parseInt(config.getString("dlt.api.request.max.count"))) {
        return false;
    }
    return true;
}

}
复制代码
It‘s current coverage is 33.3%, and the target is 85%.

Firstly, I tried to modify as below:（1st Modification）

复制代码
public class DltApiHttpRequestRetryHandler implements HttpRequestRetryHandler {

private PropertiesConfiguration config = BusinessConfigUtil.getConfiguration();
private Logger logger = LoggerFactory.getLogger(getClass());

@Override
public boolean retryRequest(IOException exception, int executionCount, HttpContext context) {
    logger.warn("(Could not execute request. Execution count) : {}.\n{}", executionCount, exception.getMessage());

    int maxCount=0;
    try {
        String strMaxCount=config.getString("dlt.api.request.max.count");
        maxCount=Integer.parseInt(strMaxCount);
    }catch(NoSuchElementException ex) {
        throw new BatchApplicationException(ex.getLocalizedMessage());
    }catch(java.lang.NumberFormatException ex) {
        throw new BatchApplicationException(ex.getLocalizedMessage());
    }

    return executionCount<maxCount;
}

}
复制代码
And after rebuilding, sonarcube told me the coverage was lowered to 20%!

I realized that more branches will bring lower coverage, on the contrary, less branches will enhance the coverage, that is a effective way!

Next,I simplified code as below:（2nd modification）

复制代码
public class DltApiHttpRequestRetryHandler implements HttpRequestRetryHandler {
private PropertiesConfiguration config = BusinessConfigUtil.getConfiguration();
private Logger logger = LoggerFactory.getLogger(getClass());

@Override
public boolean retryRequest(IOException exception, int executionCount, HttpContext context) {
    logger.warn("(Could not execute request. Execution count) : {}.\n{}", executionCount, exception.getMessage());

    return executionCount<Integer.parseInt(config.getString("dlt.api.request.max.count"));
}

}
复制代码
According to expectation, the coverage was enhanced to 42.3%, but NOT as expected,the rate is not 100% or 0%.

In my view, there is no branch in the 2nd modification so that the coverage rate should be 100% or 0% because either it was invoked, or it will never be run.

How was 42.3% calculated? This makes me confused.

Conclusion:

As we all know, the three codes are same indeed, the different sonar-cude coverage rates can‘t change the reality!

I think sonar-cude is like a black-box, in which there are something we don‘t know, maybe something in it is unreasonable and unreliable.

Obviously, the 1st code is more readable and robuster, but for it‘s lower coverage and need more test-cases(Not easy to add, you know,sometimes the branches can‘r be covered), the coder will avoid writing like this.

And there are too many functions in one line in 2nd code,it is a bad smell that so many rules told us. But for higher coverage and less test-case, the coder will tend to do so. That will result in violation of proper code style.

Better code style or higher coverage, which one we should choose? In my opinion, I prefer the former.

So I propose the coverage rate should not be the unique evidence to judge a piece of code and be the final target of coding.

Do you agree?

The relationship between Sonarcube coverage and co

标签：eal   some   you   tst   ber   either   something   throw   java   

原文地址：https://blog.51cto.com/7726611/2473027