12

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

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

我们使用了很多工具，所以也许我可以使用一个插件（jira、greenhopper、fisheye、sonar、hudson）。我还在考虑可能是 Subversion 预提交挂钩、jira 的提交接受插件或类似的东西。

想法？

4

3 回答 3

6

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

于 2011-03-02T21:08:06.727 回答
2

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

确定代码覆盖率通常可以使用多种测试覆盖率工具中的任何一种来完成。许多测试覆盖率工具可以简单地重新检测整个应用程序，然后您可以运行测试以确定覆盖率。

我们的（语义设计）测试覆盖工具系列可以从更改的文件列表中确定需要重新检测的单个文件，并通过仔细的测试组织，确定需要重新执行的测试。这将最大限度地减少重新运行测试的成本，并且您仍然会以相同的整体覆盖率数据结束。（实际上，这些工具会根据方法级别的更改检测需要进行哪些测试）。

一旦你有了测试覆盖率数据，你想知道的是一些测试覆盖了特定的新代码。如果您知道哪些文件已更改，则可以通过坚持更改的文件具有 100% 的覆盖率来草率地使用测试覆盖率数据来执行此操作。这在实践中可能行不通。

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

很容易从 SmartDifferencer 的输出中提取更改的行列表。可以计算每个文件与测试覆盖率数据覆盖的行的交集。如果更改的行不完全在涵盖的行集中，则“新”代码尚未经过测试，您可以举起标志、停止签入或其他任何表示您的检查策略已被违反的信号。

TestCoverage 和 SmartDifferencer 工具并不是开箱即用的，为您完成了这个计算，但它应该是一个非常容易实现的脚本。

于 2011-03-02T22:18:17.840 回答
0

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

于 2011-03-02T21:20:16.120 回答