Maven Cobertura 插件生成不完整的覆盖率报告答案

【问题标题】：Maven Cobertura plugin generating incomplete coverage reportMaven Cobertura 插件生成不完整的覆盖率报告
【发布时间】：2015-05-12 10:06:55
【问题描述】：

我正在使用：

mvn cobertura:cobertura

为项目生成覆盖率报告。这实际上并没有在 pom.xml 文件中配置，因此它只是使用了最新版本的插件（当前为 2.6）。

在大多数情况下，这可以正常工作，但由于某种原因，一个班级的报告非常奇怪。似乎报告了某些行已被覆盖，但其他行（就在它旁边）没有。

我一直在跑步：

mvn clean

当然，但这似乎没有帮助。

总的来说，它只报告了大约 1% 的覆盖率，但这实际上是一个非常关键的类，我知道它被大量使用。我也知道报告过去工作正常。我不确定他们什么时候停止工作，因为我已经有一段时间没有检查该课程的覆盖范围了。

作为我所看到的示例：

2053 private final List<EntityProperty<T>> properties = new ArrayList<EntityProperty<T>>();     
     private final PropertyDescriptor idProperty;
0    private final Set<String> fieldOrder = new LinkedHashSet<String>();
0    private final Map<String, String> additionalFieldLabels = new HashMap<String, String>();

这是来自类的初始化程序。第一行显然被称为 2053 时间。第 2 行实际上没有运行任何代码，因此留空（如图所示），但第 3 行和第 4 行都报告被调用 0 次。

另一个例子：

2053 public EntityIntrospector(AdminApp app, EntityApplication entityApp, Class<T> entityClass) {
0        this.app = app;

来自构造函数本身。第一行再次被调用了 2053 次，但第二行（以及构造函数中的所有其他行）被调用了 0 次。

无论如何，我不知道为什么会发生这种情况。

我怀疑可能是另一个库以某种方式干扰了覆盖/仪器。

班级规模可能是一个因素。源文件本身相当大，有 2040 行长（918 行实际代码计入覆盖范围）。

过去几天我一直在编写其他测试和代码，cobertura 对这些工作正常。

欢迎提示和建议。

【问题讨论】：

只是一个想法，即使在mvn clean 之后，如果您使用的是 IDE 左右，也可能会有剩余的编译类。干净结帐时的行为是否相同？
是的，一开始我也想知道，但确实尝试了很多次，但没有任何区别。最后，我认为这是一个班级规模的事情。无论如何，班级都获得了一点“神级”的地位。
最后似乎和构造函数中的代码有关。我在下面更新了我的答案，我改变了。

标签： java maven cobertura maven-cobertura-plugin

【解决方案1】：

所以看起来班级太大了。我对有问题的班级进行了黑客攻击，以注释掉一些行。这显然导致大量测试失败，但现在覆盖范围似乎又可以正常工作了。

这个类现在有 804 行（就可以覆盖的行而言）。

所以看起来对于一个类 cobertura 可以处理的大小有某种有效的限制。

在我的情况下，这可能意味着该类可以通过重构来分解代码。

更新（2015 年 6 月 3 日）：我将有问题的类重构为 790 行，但仍然遇到同样的问题。最后问题似乎与构造函数中的代码有关。我有类似的东西：

try {
    final BeanInfo beanInfo = Introspector.getBeanInfo(entityClass);
    // rest of constructor here (about 50 lines)
}
catch( IntrospectionException ie ) {
    throw new RuntimeException(ie);
}

我把它改成了这样的方法：

protected BeanInfo getBeanInfo(Class<T> entityClass) {
    try {
        return Introspector.getBeanInfo(entityClass);
    }
    catch( IntrospectionException ie ) {
        throw new RuntimeException(ie);
    }
}

它是从构造函数中调用的。这样我就知道不再需要构造函数本身内部的 try/catch。

我不能 100% 确定这是否通过缩短构造函数的长度来解决问题，或者移动 try/catch 是否有所作为。

【讨论】：