代码覆盖的15种典型情景

　　10、被拒绝的馈赠

　　在接口/抽象类定义的时候，有时候定义的一些方法子类并没有都实现，即常说的被拒绝的馈赠（Refused Bequest），这种问题如果是为了短期扩展需求多加了一些方法也可接受，否则还是需要重新继承体系设计。

　　提示：子类未使用“馈赠”，无需覆盖，需重新审视继承体系结构。

　　11、代码覆盖工具未做合并

　　做代码覆盖时，往往工具本身不支持“合并”的功能，这导致以下问题存在：

　　时间上：

　　例如对于拥有cache的系统： 系统经过一段时间运行后，重新测试得到的代码覆盖往往不包括cache miss的情况。

　　手工测试问题：每次统计都需要重新完成全部手工测试，否则将丢失数据。

　　空间上：

　　负载均衡：现在大多系统应用都采用负载均衡技术，如果测试时间不够长且只统计一台系统的代码覆盖情况，往往不全面。

　　提示：代码覆盖本身要支持“合并”功能，对多个系统、不同时间的数据进行合并，才能覆盖的完整全面。

　　12、系统逻辑重复

　　这里可分为两种情况：

　　组件之间重复：上层系统可能会对数据合法性做检验，但是下层系统出于系统的独立性目标，也可能对数据做二次校验，但是作为一个完整系统进行end-to-end测试时，无法覆盖二次校验的代码；针对这种情况，需要拆开成独立组件进行测试。

　　组件内部重复：同一组件内多层重复逻辑确实可以纠正代码，例如在对于某个数据做多次同一类型校验，这种问题常出现于多人协同编码又缺乏沟通的情况中。

　　提示：逻辑重复导致的部分未覆盖要分辨是组件之间还是组件内部冗余，组件之间则需要覆盖，组件内部则要修改代码。

　　13、代码写法

　　有时候某些代码的写法，也会导致无法覆盖，例如对于代码调用顺序：多个类调用读取配置文件，而稍晚些调用的再次判断配置文件是否初始化，自然为已初始化。再如对于单例，某些代码写成这样：

private static SingleInstance INSTANCE = new SingleInstance();

public static SingleInstance getInstance() {
        if (INSTANCE == null) {
            INSTANCE = new SingleInstance();
        ｝
        return INSTANCE;
}

　　提示：代码写法造成的未覆盖，需要审查下是代码问题。

　　14、隐式的分支

　　当代码中含有隐式的分支时，往往很难覆盖，例如上文提到的断言assert，貌似只有一句，但是即使启用断言仍然无法覆盖，例如下例还是显示黄色：分支未覆盖。