将科覆盖率提高到100%是非常困难的。通常的方法是使测试实例尽可能小而简单。这就是为什么很多测试实例直到目标函数的覆盖率达到可接受程度时才被用到。测试实例需通过函数的期望值测试，直到所有有意义的小目标在执行中均被测试。目标对象的状态在从测试代码里调用实函数时或许需要在外部被修改。这个过程可通过以下方式实现：

　　* 　　当它们为公有时直接改变其属性调用能改变状态的必要函数时（例如存在所需属性的设置函数）

　　* 　　间接改变其属性当目标类的属性为保护类或私有类时，我们需要一种特殊的方法，比如

　　* 　　把一个测试类定义为一个友元类，例如：

　　由测试目标类衍生一个封装类，并对其使用可在实类里成为保护类属性的函数。测试时在类里或者类函数里使用预编译，使其提供更多灵活的类属性方式。注意代码会因为预编码时存在的比较差的可读性而出现不同的断点甚至引起很难处理得新的错误。

　　接下来的一章将会介绍理论上的单元测试并提供开发单元测试时需要牢记得策略和技巧。

　　理解可测试性

　　是什么决定软件是可测试的还是不可测试的呢？通过检查现有的函数（如上一章介绍的），我们很容易可以看出在程序中添加测试程序的早晚将会产生不同的效果，如果程序的内部结构是复杂的，开发者就不必存取数据、函数和事件处理系统（当使用异步接口时）。

　　Pressman[7]定义了以下几条使软件更具测试性的原则：

　　可操作性：软件对象越易操作，就越具有可测试性。所以在默认状态下，尽可能不让代码过于膨胀冗余，及早地去除bug（在它们让你的程序死掉之前）。

　　可观察性：所见即所测。缺失的源代码或是文档将会让我们很难判断如何测试对象。不可实现的属性也将使我们很困难甚至不可能确定结果是否正确。异常和错误条件以及它们的输出都应该是有根据的以便于我们能判断我们的操作是否是我们想要的。

　　可控制性：尽可能保证函数开源以便测试能够很容易地控制测试对象。实际上，较长的代码缺失和复杂的函数使它们成为共有类或保护类。软件使用的数据需是测试程序中可实现可改变的部分。

　　可分解性：通过控制测试范围分割问题。软件是由很多小段代码组成的，这些小段代码可拿来独立测试。实际上，一个测试实例应测试一个类，所有的依赖性都应该能被小段代码和模拟对象所替代。

　　简易性：代码越少，要用的测试越少。系统里不应该存在没有用到的功能函数（删除死码）。软件结构应该是简单且模块化的。代码应该尽可能短，应具有可读性，不存在任何没用的控制架构。

　　稳定性：改动越少意味着测试所受的干扰越少。软件的改动应该是有计划可控制的。设计（和测试）的软件是用来将程序从运行失败状态恢复正常。Pressman建议缩减代码和测试的改动，然而那些思维活跃的开发者更喜欢不停地反复修改（改动代码，测试并删除不必要的代码）。

　　可理解性：测试者拥有的信息越多，测试效果越好。一般的文档已经足够了。各组件相互依赖以及内部和外部组件的使用，应该是清晰明了的。基于代码的所有改动都应该是可交流的（改动时使用版本管理系统和可视化文件比较器是比较明智的）。