测试驱动开发系列之七--监视产品代码

第八章 监视产品代码
我们会碰到一些硬件以及操作系统方面的依赖问题。我们会用到接口，测试替身，以及链接时代换来处理这些依赖。可以让测试替身替代有麻烦的依赖组件来拦截并监控接口调用。基本的想法是测试用例和测试替身一起形成一个测试夹具包围起被测代码，驱动它的输入并监视和检查它的输出。

8.1灯光调用测试列表
我们从编写一个测试列表开始。这帮助我们组织思维。我们不期望做一个完美的测试列表。可以从任何你能想到的测试开始，并且随着你了解的更多而演进测试列表。
不要再测试列表上花太多时间。如果你尝试让它变得完美，那你绝对花太多时间在这上面了。

8.4监视被测试代码
为什么是在间谍的头文件里为灯光状态定义这些文字常量而不是在产品代码的头文件里。因为这些值是间谍在测试时用作询问的。他们会污染代码。间谍的实现定义了一个秘密情报放置点，由文件作用域的数据构成，当完成它重要的隐秘操作后间谍吧情报放在其中。在被测代码执行后，通过秘密访问器从情报放置点中取出情报。

8.5控制时钟
在嵌入式系统中时钟往往关系重大。时间是一个不稳定的输入，它给测试带来了挑战。这里的底线是测试必须接管对时钟的控制。

8.6先0后1
如果从一个包含很多调度时间的测试用例开始，可能需要很多的代码。一个发起进攻并争取这类问题的切入点是从"没有"调度项的测试用例开始，然后是一个调度项，把多个的用例留在以后做。这种方法在用TDD处理集合行为时很常见。"什么也不做"的测试时通向测试通过的最短路径。它所需的只是对产品代码调用的接口定义。这里的目标是把边界测试调整正确。

为移除重复而重构
 相对于传入一个枚举类型参数，应该列举出一系列函数。这样更安全并且更具有描述性。
为责任而重构
重构测试
 把这些细节分离到测试组的辅助函数中以后，测试就会变得更容易演进了。
测试串联

8.7处理多个的情况
如果一个条件重要到在产品代码中进行检查，那么它就足够重要到需要测试。

当有集合行为时，使用0-1-N的TDD模式。0和1的情况通常来讲更容易定义，并且它帮助澄清对于接口，合作者以及一些边界行为的思路。他们为更具挑战的行为提供了垫脚石，并且帮助你进入到TDD的节奏中。

第九章 运行时绑定的测试替身
如果那些基于一部分测试的需要而被打桩掉的代码却在另一些测试当中用到该怎么办？我们需要比链接器所能提供的更多的灵活性。我们会使用函数指针，以便在同一个测试构建中既可以测试一个函数，又可以换掉它。

9.1测试随机性
 当代码依赖于某些不确定因素的时候，就是要把它用测试替身换掉的时候。
9.2仿冒函数指针

有了函数指针，测试就可以截获从被测代码发出的函数调用。它可以成为一种非常有效地手段，如外科手术般地分离开对某些函数的调用。通过函数指针来调用函数的代码最好知道它是通过指针进行调用。
对于要替换出对目标平台的依赖关系或者有时要替换掉整个第三方库来讲，它是正确的工具。函数指针为在运行时脱离依赖关系提供了一种更细致的方式。如果你在测试可执行文件中需要一段代码，但在某些测试中你又需要把它换掉，那就使用函数指针。

9.3外科手术般地插入间谍
不是所有的测试替身自己都需要测试。但在本例中，由于这个间谍有点复杂，因此需要测试。测试显示了间谍行为并且保证它能正常工作。