确保对新的Subversion提交的覆盖率最小

Question

我们有一个几乎没有单元测试的大型项目。我想从现在开始确保开发人员提交新功能（或错误！），而不会对相应的单元测试进行最小的覆盖。

有哪些方法可以强制执行此操作？

我们使用很多工具，所以也许我可以使用插件（jira，greenhopper，fisheye，sonar，hudson）。我也在考虑一个Subversion预提交钩子，jira的Commit Acceptance插件，或类似的东西。

思想？

Answer 1

使用Build breaker插件的Sonar（顺便说一句精彩的工具）可以在某些指标不符合指定规则时破坏您的Hudson构建。您可以在Sonar中设置这样的规则，当覆盖范围低于给定点时，该规则将触发警报（最终导致构建失败）。唯一的缺点是您可能希望覆盖范围增长，因此您必须记住每天将警报级别提高到当前值。

Answer 2

您要做的是确定什么是新代码，并验证某些测试是否涵盖了新代码。

通常可以使用各种测试覆盖工具来确定代码覆盖率。许多测试覆盖工具可以简单地重新检测整个应用程序，然后您可以运行测试来确定覆盖范围。

我们的（语义设计＆＃39;）line of Test Coverage工具可以从已更改的文件列表中确定需要重新检测的单个文件，并通过仔细的测试组织，只需要进行必要的测试被重新执行。这样可以最大程度地降低重新运行测试的成本，并且您仍然可以结束 具有相同的整体覆盖数据。 （实际上，这些工具根据方法级别的变化检测需要进行哪些测试）。

一旦获得测试覆盖率数据，您想知道的是某些测试涵盖的特定新代码。如果你知道哪些文件发生了变化，你可以通过坚持更改的文件100％的覆盖范围，只使用测试覆盖率数据来做到这一点。这可能在实践中不起作用。

您可以利用SD Smart Differencer tools来提供更准确的答案。这些工具比较两个语言文件，并指示更改使用语言语法的位置（例如，表达式，语句，声明，方法体，而不仅仅是更改的源行）和概念编辑操作（移动，复制，删除，插入，重命名 - 标识符内块）。 SmartDifferencer增量往往比普通差异工具更小更精细。

很容易从SmartDifferencer的输出中提取更改的行列表。可以计算每个文件与测试覆盖率数据覆盖的线的交集。如果改变的行不完全在所覆盖的行集中，那么＆＃34; new＆＃34;代码尚未经过测试，您可以举起一个标记，停止签到，或任何表明您的检查政策遭到违反的信号。

TestCoverage和SmartDifferencer工具不会为您完成此计算而开箱即用，但它应该是一个非常简单的脚本来实现。

Answer 3

如果你使用maven - cobertura插件可能是一个不错的选择（对于开发人员来说不像svn hook那么烦人） http://mojo.codehaus.org/cobertura-maven-plugin/usage.html