Sonar + JaCoco并未将Groovy代码视为已涵盖 [英] Sonar + JaCoco not counting Groovy code as covered

问题描述

我有一个带有单个静态方法的Groovy类:

I have a Groovy class with a single static method:

class ResponseUtil {
    static String FormatBigDecimalForUI (BigDecimal value){
        (value == null || value <= 0) ? '' : roundHalfEven(value)
    }
}

它有一个测试用例或几个:

It has a test case or few:

@Test
void shouldFormatValidValue () {
    assert '1.8' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(1.7992311))
    assert '0.9' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(0.872342))
}

@Test
void shouldFormatMissingValue () {
    assert '' == ResponseUtil.FormatBigDecimalForUI(null)
}

@Test
void shouldFormatInvalidValue () {
    assert '' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(0))
    assert '' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(0.0))
    assert '' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(-1.0))
}

这导致6/12个分支按Sonar/JaCoCo的规定覆盖:

This results in 6/12 branches covered according to Sonar/JaCoCo:

因此，我将代码更改为更多...冗长.我不认为原始代码太聪明"或类似的东西，但是我使它更加明确和清晰.因此，这里是:

So I've changed the code to be more...verbose. I don't think the original code is "too clever" or anything like that, but I made it more explicit and clearer. So, here it is:

static String FormatBigDecimalForUI (BigDecimal value) {
    if (value == null) {
        ''
    } else if (value <= 0) {
        ''
    } else {
        roundHalfEven(value)
    }
}

现在，Sonar/JaCoCo在未做任何其他更改的情况下报告已将其完全覆盖:

And now, without having changed anything else, Sonar/JaCoCo report it to be fully covered:

为什么会这样?

推荐答案

我不知道它是否适用于您的具体示例，但是请记住，代码覆盖率工具通常不适用于替代JVM语言，除非它们明确支持他们.这是因为实际上所有这些语言都会生成额外的字节码，这些字节码只能在某些情况下执行.例如，Groovy可能会为慢速路径和快速路径生成字节码，并可能在用户之间没有发言权的情况下自动决定它们.

I don't know if it applies to your concrete example, but keep in mind that code coverage tools typically don't work well for alternative JVM languages unless they support them explicitly. This is because virtually all of those languages generate extra byte code that may only get executed in certain cases. For example, Groovy might generate byte code for a slow path and a fast path, and might decide between them automatically, without the user having a say.

使用Groovy 3.0可能会改善这种情况，它将围绕Java invokedynamic设计，这意味着必须生成更少的魔术"字节代码.同时，我听说Clover具有明确的Groovy支持，尽管我不知道它是最新的.

The situation might improve with Groovy 3.0, which will be designed around Java invokedynamic, meaning that less "magic" byte code will have to be generated. Meanwhile, I've heard that Clover has explicit Groovy support, although I don't know how up-to-date it is.

这篇关于Sonar + JaCoco并未将Groovy代码视为已涵盖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！