将代码覆盖率与版本控制联系起来答案

【问题标题】：Linking code coverage to version control将代码覆盖率与版本控制联系起来
【发布时间】：2011-06-21 10:56:41
【问题描述】：

在我提交更改之前，我想确保所有这些都已通过代码覆盖率报告自动或手动进行测试，但是有很多遗留代码没有自动测试，并且不会受到我的更改的影响。

是否有工具可以交叉引用来自版本控制工具的差异和代码覆盖率报告，并确保所有已更改的内容都已运行？

我意识到，对于代码覆盖，这可能会给人一种虚假的安全感，而对于这样的事情，更是如此，但我认为这值得一试。我使用 git 和 PHP - 我使用 XCache 的代码覆盖器界面来浏览我运行的内容，它很有用，但如果某些东西可以在 git commit 或 push 时自动运行，那就太好了。

【问题讨论】：

【解决方案1】：

对于git diff，有一个名为diff-cover 的工具，可以检查覆盖率。它获取 Cobertura XML 覆盖率报告并与git diff 的输出进行比较。然后它报告差异中行的覆盖率信息。

给定正确的覆盖率 xml 文件，您可以使用此命令检查与master 分支相比所做更改的覆盖率：

$ diff-cover coverage.xml

与 CI 服务器集成也非常简单，只要它可以为您提供需要比较的提交，例如 Jenkins 中的 $GIT_PREVIOUS_COMMIT。

【讨论】：

在运行 PHP 单元测试时如何获得 Cobertura XML 格式？当将此工具与--coverage-clover=coverage.xml 一起使用时，AttributeError: 'NoneType' object has no attribute 'replace' 会出错

【解决方案2】：

您可以设置一个continuous integration 构建服务器（有很多excellent, free build servers）。构建步骤之一是运行代码覆盖率。您可以将其设置为忽略遗留代码并仅计算非遗留代码的覆盖率。然后，如果覆盖率

【讨论】：

好主意；在每次签入或推送时进行代码覆盖等繁重的工作会使版本控制使用起来更加痛苦，因此人们会讨厌它。相反，根本不要让人们推入主线；在持续集成服务器中测试人们的分支（我喜欢 gitbuilder），然后只有在持续集成批准后才将这些分支合并到主线中。
重读我的问题，我强调错了。关键不是它在提交时运行并阻止我提交。关键是我可以确定我已经运行了所有我在提交之前更改的代码。能够在提交/推送时自动运行只是一个小小的好处，而不是真正的要求。
@rjmunro：我知道我的答案并不完全符合您的要求，但我认为它已经尽可能接近了。