Eclipse的有效代码覆盖率-CSDN博客

俗话说傻瓜用工具还是傻瓜 。但是，对我而言，如何最有效地使用工具并不总是显而易见的。因此，我通常会花一些时间检查新的游乐场¹ ，这些游乐场有望在不降低质量的情况下提高我的工作速度。这样，我遇到了EclEmma ，这是Eclipse IDE的代码覆盖工具，对于实现全面的测试用例非常有用。

覆盖范围

通常，“ 测试覆盖率是查找代码库中未经测试的部分的有用工具 ”，因为“ 测试驱动开发是一种非常有用的工具，但肯定不足以帮助您获得良好的测试 ”，正如Martin Fowler所说² 。鉴于此，分析代码库中未经测试的零件的通常方法是不时地运行适当的工具，或者是例如每晚生成一次自动生成的报告。

但是，第一种方法似乎有点不确定性，第二种方法则存在着专注于高数字³而不是测试质量的危险。更不用说上下文切换的成本了，扩大了几天或几周前您写的空白处的覆盖范围。

因此，保罗·约翰逊（ Paul Johnson）建议“ 在开发过程中尽早使用它 ”，并“ 在代码覆盖率范围内定期运行测试 ” ⁴ 。但是什么时候才尽早？再次想到，我想到在即将完成某个被测单元的工作之前的那一刻应该是理想的。由于此时应该编写所有单元的测试并进行所有的重构，因此快速检查覆盖范围可能会发现被忽略的段落。那时消除差距将以最小的代价实现，因为不会涉及上下文切换。

当然，最后一段中最重要的词是“ 快速” ，这意味着这种方法仅在可以快速收集覆盖范围数据并且易于检查结果的情况下才可行。幸运的是，EclEmma通过提供启动配置，适当的快捷方式和突出显示编辑器的功能来无缝地集成到Eclipse中，从而完全满足这些要求，而不会给开发人员带来任何代码检测负担。

埃玛

在Eclipse中，有几种方法可以快速执行测试用例⁵ 。而EclEmma使得重新运行最新的测试启动非常容易，例如通过快捷键Ctrl + Shift + F11 。由于“测试驱动开发”要求测试用例必须非常快地运行，因此相关的数据收集也必须非常快地运行。这意味着人们可以一种飞越模式真正检查被测设备的覆盖范围。

数据收集完成后，覆盖率统计信息将显示在结果视图中。但是只运行一个或几个测试用例，那么所有数字将是非常糟糕的。更有趣的是代码编辑器中的突出显示：

该图显示了如果已达到完整的指导和分支覆盖范围，则称为所谓的愉快情况。但是，不能仅通过全面覆盖就足以证明基础测试的质量！ ⁶得出的唯一合理结论是，显然没有发现任何斑点，并且如果对测试进行透彻周到的撰写，则可以宣布该单元的开发已完成。

但是，如果我们得到如下图所示的结果，则肯定没有完成：

如您所见，测试没有涵盖多个分支，并且完全遗漏了一条语句，这意味着仍有工作要做。显而易见的解决方案是添加一些测试以弥合差距。但是根据Brian Marick的说法，这种差距可能表明您的测试案例中存在一个更根本的问题，即遗漏错误 ⁷ 。因此，建议完全重新考虑测试用例。

有时您可能需要除指令计数器和分支计数器以外的其他指标。在这种情况下，您可以在报告视图中深入到当前正在处理的类，然后选择一个合适的类，如下所示：

结论

尽管可以对一般报道的内容以及如何解释报告进行更多的讨论，但是我让更多的人像这篇文章的脚注中提到的那样来呼吁人们。总结一下可以说，对良好的测试而言，全面覆盖是必要但不充分的标准。但请注意，并非总是可以实现全部覆盖，或者实现成本过高。因此，请注意不要过度操作-或再次引用Martin Fowler的话：“ 我会怀疑100％之类的东西-闻到有人编写测试以使覆盖范围满意，但没有考虑他们在做什么 ” ² 。

考虑到您的同事遵循相同的模式和原则，通常使用至少在一段时间之后……，按照本文中描述的方法，数字通常会落在项目范围覆盖率较低的90年代⁸ 。

关于软件开发，此类游乐场可能是方法论，开发技术，框架，库，当然还有工具的使用
TestCoverage ，马丁·福勒（Martin Fowler），4/ 17/2012
见仪表板促进愤慨， Sriram Narayan ，2011年4月11日
测试和代码覆盖率，保罗·约翰逊，2002年
另请参阅在Eclipse中有效使用JUnit
为了清楚地说明这一点，只需注释掉一个测试用例中的每个断言和验证，该测试用例将产生如上所示的完整覆盖范围。这样做通常应该根本不更改覆盖率报告，尽管测试用例现在已经毫无用处了
如何滥用代码覆盖率 Brian Marick
请记住，数字取决于所选的指标。路径覆盖率通常小于分支覆盖率，分支覆盖率可以小于语句覆盖率