测试驱动开发系列之八--测试有合作者的模块

测试有合作者的模块

7.1合作者
合作者(collaborator)就是在被测代码(Code Under Test CUT)之外的一些函数，数据，模块或者设备，并且CUT依赖于它们。
测试替身在测试时会模仿一些函数，数据，模块或库。被测试的代码并不知道它在使用测试替身，它与替身之间的交互和与真实的合作者采用同样的方式。测试替身最简单的形式就是一个桩。

7.2脱离依赖关系
测试要对自己的四个阶段负责:建立，执行，验证和清理。测试的依赖关系混乱来自于它要满足自身在四段测试模式的责任。
我们其实可以吧代码设计得更容易测试，这样就可以脱离有问题的依赖关系。脱离依赖关系的关键在于更严格地使用接口，封装，数据隐藏，以及减少对没有保护的全局数据的依赖。为了设计更模块化并具有可测性的C程序，我们使用一个头文件来公布模块的接口。可测试的模块会通过模块的接口与其他模块交互。

7.3何时使用测试替身

如果合作者成为你自动化测试的阻碍，那么就是应该使用测试替身的时候了。
不是所有的交互都会用到测试替身。我的经验法则是如果可以就用真实代码，只有必要时才使用测试替身。何时仿冒何时不仿冒需要运用自己的判断来决定。
这几个是使用测试替身的常见理由:
1.独立于硬件
2.注入难以产生的输入
3.加速缓慢的合作者:像数据库，网络服务或者数字计算等动作缓慢的合作者，可以通过返回一个由测试用例控制的结果来仿冒，从而提高测试速度。
4.依赖于不稳定的事物:不稳定合作者的一个经典的例子就是时钟。
5.对在开发的事物的依赖:当访问一个未知区域时，可以开发一个测试替身，它带有被测代码的所有接口。被测试代码的进度仍可以继续，同时也有机会来探索被测代码对于现在尚未实现的服务的需求。
6.对于难以配置的事物的依赖:如果一个DOC很难配置和被设置到一个或多个期望的状态，可能最好的办法还是用测试替身来换掉它。数据库就是一个很好的例子，你的确可以测试它，但是这样的测试很难配置。

7.4用C语言来仿冒
1.测试哑元(test Dummy) 让链接器不会拒绝你的构建。一个哑元就是一个从来不会被调用的简单的桩。提供它是为了让编译器，链接器或者运行时依赖满意。
2.测试桩(test Stub)在当前的测试用例的指示下返回某些值。
3.测试间谍(test Spy)捕获由被测代码传出的参数。，以便测试可以校验由被测代码传出的参数是否正确。间谍也可以像测试桩一样提供返回值。
4.仿制对象(mock object)校验函数调用，调用顺序，以及从被测试代码传向DOC的参数。它还可以设定向被测代码返回指定的值。仿制对象通常用于处理有多个对其调用的情形，并且每个调用和响应都潜在不同。
5.仿冒对象(foke object):为其替代的组件提供一个部分的实现。与其替代的实现相比，仿冒通常有更简单的实现。
6.引爆仿冒(exploding fake):当调用到其时引发测试失败。

C语言有三种原型机制来实现仿冒
1.链接时替换
 在你不能控制模块接口的地方，你需要用链接代换来换掉它。这种技术对脱离目标的测试以及消除对第三方库依附于硬件的模块或者操作系统的依赖特别有帮助。
2.函数指针代换
 在你希望只为一部分测试用例替换DOC的时候可以使用函数指针。你可以在任何你可以控制接口的地方使用函数指针。函数指针对重载哪些函数，不重载哪些有强大的控制力。
3.预编译代换
 你可以用预编译来断开一系列不想要的包含，你也可以用它有选择性地或临时地重载名字。预编译代换是代换的最后选择。它对代码所渗透的改变时深远的。
4.组合链接时和函数指针代换