Maven Cobertura 插件生成不完整的覆盖率报告
Maven Cobertura plugin generating incomplete coverage report
我正在使用:
mvn cobertura:cobertura
为项目生成覆盖率报告。这实际上并没有在 pom.xml 文件中配置,所以它只是使用最新版本的插件(当前为 2.6)。
在大多数情况下这工作正常,但由于某种原因 class 有一个非常奇怪的报告。似乎报告说有些行已被覆盖,但其他行(紧挨着它的行)没有。
我已经运行宁:
mvn clean
当然,但这似乎没有帮助。
总的来说它只报告了大约 1% 的覆盖率,但这实际上是一个非常重要的 class 我知道它被广泛使用。我也知道报告过去工作正常。我不确定他们什么时候停止工作,因为我已经有一段时间没有检查 class 的覆盖范围了。
作为我所看到的示例:
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>();
这是来自 class 的初始化程序。第一行显然被称为 2053 时间。第 2 行实际上 运行 没有任何代码,因此留空(如所示),但第 3 行和第 4 行都报告被调用 0 次。
另一个例子:
2053 public EntityIntrospector(AdminApp app, EntityApplication entityApp, Class<T> entityClass) {
0 this.app = app;
来自构造函数本身。同样,第一行被调用了 2053 次,但第二行(以及构造函数中的所有其他行)被调用了 0 次。
无论如何,我不知道为什么会这样。
我怀疑可能是另一个库以某种方式干扰了 coverage/instrumentation。
class 大小可能是一个因素。源文件本身有 2040 行长(计入覆盖率的实际代码行 918 行)。
过去几天我一直在编写其他测试和代码,cobertura 可以很好地完成这些工作。
欢迎提出提示和建议。
所以 class 似乎确实太大了。我破解了有问题的 class 以注释掉一些行。这显然导致大量测试失败,但覆盖范围现在似乎再次正常工作。
class 现在是 804 行长(就可以覆盖的行而言)。
所以看起来 class cobertura 可以处理的大小有某种有效限制。
在我的例子中,这可能意味着 class 可以通过重构来分解代码。
更新(2015 年 6 月 3 日):
我将有问题的 class 重构为 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 是否有所不同。
我正在使用:
mvn cobertura:cobertura
为项目生成覆盖率报告。这实际上并没有在 pom.xml 文件中配置,所以它只是使用最新版本的插件(当前为 2.6)。
在大多数情况下这工作正常,但由于某种原因 class 有一个非常奇怪的报告。似乎报告说有些行已被覆盖,但其他行(紧挨着它的行)没有。
我已经运行宁:
mvn clean
当然,但这似乎没有帮助。
总的来说它只报告了大约 1% 的覆盖率,但这实际上是一个非常重要的 class 我知道它被广泛使用。我也知道报告过去工作正常。我不确定他们什么时候停止工作,因为我已经有一段时间没有检查 class 的覆盖范围了。
作为我所看到的示例:
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>();
这是来自 class 的初始化程序。第一行显然被称为 2053 时间。第 2 行实际上 运行 没有任何代码,因此留空(如所示),但第 3 行和第 4 行都报告被调用 0 次。
另一个例子:
2053 public EntityIntrospector(AdminApp app, EntityApplication entityApp, Class<T> entityClass) {
0 this.app = app;
来自构造函数本身。同样,第一行被调用了 2053 次,但第二行(以及构造函数中的所有其他行)被调用了 0 次。
无论如何,我不知道为什么会这样。
我怀疑可能是另一个库以某种方式干扰了 coverage/instrumentation。
class 大小可能是一个因素。源文件本身有 2040 行长(计入覆盖率的实际代码行 918 行)。
过去几天我一直在编写其他测试和代码,cobertura 可以很好地完成这些工作。
欢迎提出提示和建议。
所以 class 似乎确实太大了。我破解了有问题的 class 以注释掉一些行。这显然导致大量测试失败,但覆盖范围现在似乎再次正常工作。
class 现在是 804 行长(就可以覆盖的行而言)。
所以看起来 class cobertura 可以处理的大小有某种有效限制。
在我的例子中,这可能意味着 class 可以通过重构来分解代码。
更新(2015 年 6 月 3 日): 我将有问题的 class 重构为 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 是否有所不同。