新代码行的代码覆盖质量门

Question

对于 Java 应用程序，是否有人对如何构建质量门有任何建议，以防止合并没有至少 80% 代码覆盖率的新代码？我们正在使用遗留代码库，虽然我们希望看到覆盖率得到改善，但我们希望停止流失并对新代码实施适当的测试覆盖率。

我已经看到了有关使用 gitblame 和排除/包含列表与 SonarQube 或 JaCoCo 结合使用的建议，但是这将报告整个类的覆盖范围，而不仅仅是新的/更改的行，因此我们可能会遇到一个问题，其中由于缺乏遗留覆盖范围，合并被阻止。

Answer 1

您正在寻找的是新代码的覆盖率，它包含在默认质量门中，要求达到 80%。

不幸的是，由于您希望将低覆盖率分支阻止合并到主分支中，这意味着您需要进行稳健的分支分析。这是在计划中的，但我们还没有实现。此外，PR 分析（在处理分支机构时始终是第一个候选者）也无济于事，因为 a）它不考虑覆盖范围 b）它不检查分支机构的质量门状态（技术上没有 QG） PR 状态）

作为（有点痛苦，但可能可以自动化）解决方法：

^{*或者任何让你快乐的价值}

郑重声明，本文中的“新代码”是指自泄漏期开始以来添加的行和修改的（旧）行。泄漏期可以定义为最近 X 天（次优）、自给定日期（更好但仍不完美）、自特定版本以来或自

previous_version

以来，这将为您提供跟随版本更改的浮动泄漏期。为了确保投入生产的新代码满足您的质量要求，建议使用最后一个，但这意味着输入到分析中的版本字符串需要保持最新。

编辑21年6月21日 新代码覆盖率测量现在可用于所有商业版本中的分支机构和 PR。

Answer 2

此工具支持 Jacoco 格式，并且只会因更改的行而出错。

这是用 PHP 编写的（因此您需要在 CI 服务器上安装 PHP）

如果您正常生成 Jacoco 报告，然后使用

git diff origin/master... > diff.txt

./diffFilter --jacoco diff.txt jacoco.xml 80

如果更改的行覆盖率低于 80%（并显示丢失行的列表），这将失败，而对于任何> 80% 的内容，此操作将失败（还显示丢失行的列表，如果适用）

如果您修改旧代码，该工具也会因缺乏遗留覆盖而失败。（您可能应该对您正在更改的代码至少进行 1 次测试）。这可能会减慢一些更改的速度，但您将覆盖所有修改的区域，这将使未来的事情变得更好

Answer 3

我们看到许多组织强制执行代码覆盖率和质量关卡，如果未达到 80% 的覆盖率，就会停止新版本的发布。因此，工程团队对寻找通过有意义的测试快速实现这一目标的方法产生了巨大的兴趣。

Diffblue Cover 旨在“开箱即用”获得良好的覆盖范围，无需任何配置。更多：