Eclipse中的高效代码覆盖

拧巴人

有句谚语说：使用工具的笨蛋仍然是个笨蛋。但是，我对如何有效的使用工具并不十分敏感。由于这个原因通常我会花一些时间学习新的技术[1]，以保证在不影响质量的前提下提高工作速度。在这个过程中我发现了EclEmma。它是一个适用于Eclipse IDE的代码覆盖工具，对于实现全面的测试用例非常有用。

覆盖

通常，测试覆盖是一种用来发现代码库中未被测试的代码的工具，因为正如Martin Fowler[2]所说，测试驱动开发是一种能够帮助你实现良好测试的实用工具，但并不完美。基于这个原因，查找代码库中未被测试的部分最有效的方法无非是时常执行合适的测试工具程序，或自动生成报告，例如使用每日构建方式。

然而，第一种方式似乎显得有点不负责任，而第二种涵盖了过多的东西从而会影响测试质量[3]。更不用说花费在上下文转化中的代价，扩展覆盖需要测试你在几天前或几周前写的代码。

因此，Paul Johnson建议在开发过程中尽早使用测试工具，定期的使用代码覆盖测试程序[4]。但是，到底什么时候算是尽早呢？对于第二种方法我认为最佳的时刻是在完成单元测试之前。因为这个时刻所有的单元测试都会被写入，所有的重构也应该完成，此时进行快速覆盖能够检查出代码被忽略的部分。同时，如果在这个过程中修复代码会花费最小的代价，因为这时并不涉及上下文切换。

当然，在上一段中最重要的一个词就是“快”，这也就意味着这种方式只有在覆盖数据能够快速被收集、结果非常容易检查的情况下才适用。幸运的是EclEmma可以无缝的整合在Ecelipse中，通过提供启动配置，合适的快捷方式以及代码的高亮显示能很好的满足以上的要求，并不会给开发者增加代码处理的负担。

EclEmma

在Eclipse中若干种快速运行测试用例的方法[5]。但EclEmma可以使用快捷键Ctrl+Shift+F11重新启动最近一次的测试程序。由于测试驱动开发要求测试用例运行速度很快，其相关的测试数据收集也需要很快。这意味着能够在测试过程中检测单元测试的覆盖真的很快。

一旦数据收集完成，覆盖统计就会在结果中显示出来。但是仅仅运行一个或几个测试用例，整体的结果会很糟糕。最有趣的是代码编辑器中的高亮显示：
高亮显示

该图片显示了所谓的最好测试用例，所有的说明都和分支都被覆盖了。但是这不足以说明全覆盖对底层的测试一无所知[6]。唯一合理的结论是：如果代码编写过程中考虑的详尽周到，应该没有明显的未覆盖盲区，该单元的开发可能宣布完成。

但是，如果我们得到的结果如下图所示，该模块一定没有完成：

正如你所看到了的测试并没有覆盖所有的分支，而且完全遗漏了一个声明，这意味着我们还有未完成的工作。最好的解决办法就是添加一些新的测试消除这些盲区。但是，根据Brain Marick的说法，这些盲区可能意味着你的测试用例里有更多的基础问题，被称为“忽略错误”[7]。所以，最好还是重新考虑一下测试用例。

有时你可能需要除了指令和分支计数器以外的方式度量测试结果。这种情况下，你只需要点击当前类中的报告视图即可查看各种覆盖指标，具体如下图所示：

结论

关于代码覆盖以及如何解释报告还有很多东西可讲，我在这里就不多说了。请大家参考文章注脚中提到的参考文献。总结的说，全覆盖是良好测试的一个必要但非充分条件。但值得注意的是，全覆盖并不总是可以实现，或者因为其不合理的代价无法实现。所以要记住，不要过度的苛求全覆盖，或者说再次引述Martin Fowler的话：我怀疑完美的东西，比如人们写测试用例提高覆盖数量，但却并不知道他们在做什么[2]。

使用最后提到的这种方法，通常使得项目的覆盖率低于90%[8]。鉴于此，你的同事们也需要使用相同的模型和规则，至少在一段时间内，我的同事们是这样做的。

1.软件开发过程中的场景包括方法、开发技术、框架、类库以及工具。

2.测试覆盖Martin Fowler, 4/17/2012

3、参考Dashboards promote ingnorance Sriram Narayan,4/11/2011

4、测试及代码覆盖 Paul Johnson 2002

5、参考Eclipse中高效的使用JUnit

6、为了说明这点，将产生全覆盖测试用例中的断言和验证信息注释掉。这样做通常不会影响测试报告，这时候测试用例已经没有意义了。

7、Brian Marick写的如何错误的使用了代码覆盖

8、记住我们的指标取决于选定的标准，通常路径比分支覆盖小，分支覆盖可以小于语句覆盖。

myou525

这个工具是专门的代码覆盖率的，也就是基于JUnit单元测试的，可以方便的进行单元测试

我的老家

这个工具是专门的代码覆盖率的，也就是基于JUnit单元测试的，可以方便的进行单元测试