4

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

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

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

@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 覆盖的分支：

一半的代码覆盖率

因此，我将代码更改为更...详细。我不认为原始代码“太聪明”或类似的东西，但我让它更加明确和清晰。所以，这里是：

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

现在，在没有更改任何其他内容的情况下，Sonar/JaCoCo 报告它已被完全覆盖：

JaCoCo 100% 覆盖率

为什么会这样？

4

2 回答 2

3

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

Groovy 3.0 可能会改善这种情况，它将围绕 Java 调用动态进行设计，这意味着必须生成更少的“神奇”字节码。同时，我听说 Clover 有明确的 Groovy 支持，虽然我不知道它是最新的。

于 2012-06-20T18:13:07.513 回答
1

因此，事实证明，Sonar 的 Jacoco 插件显式查找 Java 代码。我知道这一点，因为我通过它进行了调试。它解码 jacoco exec 文件并假定任何文件都是 JavaFile，它没有找到，然后说您没有覆盖信息。

因此，我获取了 Jacoco 插件的源代码（它从他们的 Subversion 存储库中消失了，并且从未出现在我能找到的 Github 上）并将其折叠成一个新的 Groovy 插件。我更新的一个使用 Codenarc 0.18.1（它将 Narc 从 32 增加到 305）并识别任何类型的 Jacoco 文件 - 现有插件中的代码是不必要的错误。

源代码在这里：https ://github.com/rvowles/sonar-groovy - 只需构建它并将其放在您的扩展/插件目录中。

于 2013-05-11T04:16:15.323 回答