代码质量之测试覆盖率

统计测试代码的增长趋势的方式有：1.统计测试用例数量，及测试成功的用例数量  2. 统计测试覆盖率

用例之间的覆盖贡献率差别可能很大，简单的用例只能覆盖到极少数的几行的代码，而复杂的用例则有可能覆盖到上千行代码，这种情况下用例数量的参考价值就变的很小。还有就是用例之间还存在着重复测试的情况，如果多个用例对应的都是同一段代码，那么它们充其量只能计一个有效用例。

个人在实践的过程中基本采用第二种，统计测试覆盖率，并且是覆盖率的狂热崇拜者，到了能为之废寝忘食的地步。

最早的时候，通过打印日志或者debug代码，看看设想中的逻辑是不是都被运行正确了。

那种方式只能做到自己心中有数，但谈不上有何真正意义的统计价值。后来慢慢学会使用各种工具插件来统计，常见的有cobertura-maven-plugin和Atlassian Clover，前者为开源插件，可方便的集成到maven project中，生成网页版的统计结果，但其内容稍显单薄，只有各种层级（project、package、class）的行覆盖率和分支覆盖率及复杂度，且当项目为multi-modules的结构时，只能给出各个module的单独的覆盖率统计，没有汇总，这个在某些时候很要命，尤其是项目按service、dao、model这样分module时。Cobertura同时也是Sonar中默认的测试覆盖率统计插件。

         相比Cobertura，Atlassian公司的 Clover插件则要强大很多，能解决各种开源插件处理不了的问题，包括上面说的multi-modules的测试覆盖率统计问题。但其价格也不菲，server版的要1200$/每机器。其还提供为期一个月的试用版license，当下我正拿着试用的license，拼命的完善个人代码的测试覆盖率中。下图详细介绍了clover测试报告首页的各种统计信息。各个维度还可具体展开查看，比如单个用例为哪些class贡献了多少的覆盖率等等。

     

 

 

对照这份统计报告，如果你的覆盖率还有完善的余地，那么拿危险性最大的class开刀就行了。处理掉一批，重新运行，再对下一批进行处理，直到每个class的覆盖率都到安全线以上为止。处理的过程中，有时候能发现一些代码中的臭虫，比如某些分支死活测试不到，那就有必要检查下是不是有bug存在，或者调整下代码逻辑了。在对每个class，每个method进行分析的过程中，相当于做了一遍code review，能发现不少需要重构的地方。有Test保驾护航，重构起来自然是如鱼得水。此时已经搞不清是 Test drive Development 还是 Test drive Design。Test和代码，浑然一体。

 

通常，对平常工作中的业务代码，写单元测试要做的就是尽可能的模拟各种业务场景，创造各种场景下的具体数据。这个我觉得不难，我写的责任模块的测试覆盖率至少在85%以上。但是对于底层框架类的代码，想要这么高的测试覆盖率可谓难于上青天。框架需要模拟各种多线程、web容器、DB，甚至WS服务、LDAP服务、FTP服务、JMS等。每一个都够头疼一阵子。好在现在各种容器/服务基本都有了可embedded的JAVA版的开源工具，能比较方便的集成嵌入到单元测试代码中来。

 

提高测试覆盖率的方法无外乎两种，一、添加单元测试 二、删除不必要的代码。

 

个人总结完善覆盖率会经历下面三个阶段：

0% 到 60% 跑马圈地阶段，怎么写怎么有。

      60% 到 85% 精耕细作阶段。

85% 以上，要么是登峰造极了，要么是走火入魔、覆盖率中毒了，不到100%不罢休，getter、setter 方法和catch exception也不放过。无论是哪一种，需要有偏执的秉性。

 

最后，测试的代码应该写的比业务代码更漂亮才对。业务代码经常改来改去，熵增是跑不掉的，日积月累，积重难返。但测试代码不需要，测试代码只依赖被测试的接口，本身的代码并不需要动来动去。