确保对新Subversion提交的覆盖率最小
我们有一个大型项目，几乎没有任何unit testing。 我想从现在开始确保开发人员提交新function（或错误！），而没有相应unit testing的最小覆盖范围。
有哪些方法可以强制执行此操作？
我们使用很多工具，所以也许我可以使用插件（jira，greenhopper，fisheye，sonar，hudson）。 我也在考虑一个Subversion预提交钩子，jira的Commit Acceptance插件，或类似的东西。
思考？
使用Build breaker插件的Sonar（顺便说一句很棒的工具）可以在某些指标不符合指定规则时破坏您的Hudson构建。 您可以在Sonar中设置这样的规则，当覆盖范围低于给定点时，该规则将触发警报（最终导致构建失败）。 唯一的缺点是您可能希望覆盖范围增长，因此您必须记住每天将警报级别提高到当前值。
您要做的是确定什么是新代码，并validation某些测试是否涵盖了新代码。
通常可以使用各种测试覆盖工具来确定代码覆盖率。 许多测试覆盖工具可以简单地重新检测整个应用程序，然后您可以运行测试来确定覆盖范围。
我们的（语义设计） 测试覆盖率工具系列可以从更改的文件列表中确定需要重新检测的单个文件，并通过仔细的测试组织，确定需要重新执行的测试。 这将最大程度地降低重新运行测试的成本，并且您仍将以相同的整体覆盖率数据结束。 （实际上，这些工具根据方法级别的变化检测需要进行哪些测试）。
一旦有了测试覆盖率数据，您想知道的是一些测试所涵盖的特定新代码。 如果您知道哪些文件发生了变化，您可以通过坚持更改的文件具有100％的覆盖率，仅使用测试覆盖率数据来执行此操作。 这可能在实践中不起作用。
您可以使用SD的Smart Differencer工具来提供更精确的答案。 这些工具比较两个语言文件，并指示更改使用语言语法的位置（例如，表达式，语句，声明，方法体，而不仅仅是更改的源行）和概念编辑操作（移动，复制，删除，插入，重命名 – 标识符内块）。 SmartDifferencer增量往往比普通diff工具更小更精细。
很容易从SmartDifferencer的输出中提取更改的行列表。 可以计算每个文件与测试覆盖率数据覆盖的线的交集。 如果更改的行不完全在所涵盖的行集中，那么“新”代码尚未经过测试，您可以举起一个标志，停止签入，或任何表示您的检查策略被违反的信号。
TestCoverage和SmartDifferencer工具并没有为您完成此计算的开箱即用，但它应该是一个非常容易实现的脚本。
如果你使用maven – cobertura插件可能是一个不错的选择（对于开发人员来说不像svn hook那么烦人） http://mojo.codehaus.org/cobertura-maven-plugin/usage.html