【发布时间】:2014-09-24 07:09:12
【问题描述】:
至少可以说,我为解决这个问题所做的尝试非常辛苦,而且我已经浏览了可以在网上找到的每一个支持文档。我会马上解决的。我们正在运行黑盒测试...很多黑盒测试...从它们生成代码覆盖率的唯一方法是以老式方式将 JaCoCo 代理传递给 JVM。
我们没有使用故障保护来运行这些测试,而是使用内部套件。这是一个多模块 maven 项目,这意味着这个 JaCoCo exec 文件是在 groupId/artifactId 层次结构中生成的:
- /com/mycompany/artifact1/...
- /com/mycompany/artifact2/...
等等。
但是,项目主干显然不符合这种结构。像这样从 exec 文件手动生成 HTML 报告有点棘手(因为您只能为其提供单个源目录,并且它会期望在根目录中看到一个“com”文件夹),但这是完全合理的,非常有可能,并且已经完成。
但是,当我们使用参数触发声纳分析时
-Dsonar.itReportPath=/opt/jacoco/it-report.exec -Dsonar.dynamicAnalysis=reuseReports
Sonar JaCoCo 插件产生的结果令人失望:
[INFO] [21:34:28.406] Sensor JaCoCoItSensor...
[INFO] [21:34:28.406] Project coverage is set to 0% as no JaCoCo execution data has been dumped: /opt/jacoco/it-report.exec
[INFO] [21:34:28.444] No information about coverage per test.
现在理论很疯狂,但我想在这里尝试一下,以免再次发生意外,因为我们的构建过程有一百个活动部件,无缘无故地重新配置它会浪费很多很多工作时间。
之所以如此令人沮丧,是因为我发现的几乎所有处理 Sonar 中 IT 覆盖的解决方案似乎都遵循以下相同的公式:
- 将 JaCoCo 代理附加到 JVM
- 定义指向报告的 sonar.jacoco.itReportPath 属性
- 按下一个按钮
- 享受 IT 覆盖
我们正在使用 SonarQube 3.6.1,我们将尝试尽快升级到 4.5。这是第一步。与此同时,任何人都知道这笔交易是什么,Sonar 是否有任何理由不重用这份报告?目录层次结构有那么大吗?找到嵌套在文件树中的 groupID 文件夹并不难。升级到 4.5 就可以解决这个问题吗?
我快没油了,我会很感激我能得到的。
编辑 1:将尝试从代理分析中将 3rd 方 jar 列入黑名单。这将是一个痛苦。我不确定 JaCoCo 代理 -include 标志是否会自动排除该范围之外的任何内容,但我自己将该功能构建到 JaCoCo 中可能会更容易,而不是挖掘有许多第 3 方 groupIds 并将它们全部列入黑名单(然后必须在以后维护它。)
我有一种很好的感觉,当 SonarQube 看到 3rd 方覆盖时,它会拒绝 exec 文件。
编辑 2:从 JaCoCo 分析中成功将 3rd 方类列入黑名单。
[INFO] [10:34:05.347] Sensor JaCoCoItSensor...
[INFO] [10:34:05.352] Project coverage is set to 0% as no JaCoCo execution data has been dumped: /opt/jacoco/it-report.exec
[INFO] [10:34:06.179] No information about coverage per test.
没有。
【问题讨论】:
标签: java maven functional-testing sonarqube jacoco