通常单元测试有两个公认的约束需要满足:

　　快

　　隔离依赖.

　　重申一遍结论是: 在满足单元测试的快和隔离依赖的前提下，

　　优先选择基于状态的黑盒测试(可使用手写stub或mock退化的stub)

　　除非交互和行为本身是需求(可使用mock对象的全部特性)

　　Q: 怎么测 private 函数?

　　A: 把它变成 public 的.

　　我是认真的. 如果发现 private 函数无法简单的通过某个public函数的测试来覆盖而需要专门的测试， 意味着你的单元可能承担了太多的职责， 应该拆分到一个单独的单元中， 并开放为 public 函数.

　　如果使用 C++， 在测试环境中 #define private public.

　　如果使用 g++， 在测试环境中加入 -fno-access-control.

　　Q: 类似 private， 一些意图实现良好设计的语言特性， 如 static， sealed， final， 非虚函数等， 却总是给代码的易测试性带来麻烦， 该如何取舍?

　　A: 没什么好办法. 这些语言特性和测试的目的是相同的， 都是为提高代码质量， 减少出错的可能， 虽殊途同归， 但却互相限制， 效果也不一样.

　　我认为工业界是时候严肃认真的考虑测试环境了， 好在语言中内建对测试的支持， 一些为产品环境设计的语言特性， 应该在测试环境中关闭， 而在产品环境中生效. 其实之前很多编译器都支持 Release 和 Debug 两种环境， 也是从代码质量的方面考虑的. 现在毫无疑问证实单元测试比 Debug 更有效， 是时候与时俱进增加对 Test 的支持而逐渐罢黜对 Debug 的支持.

　　在语言本身增加对测试的支持之前， 我们不得不想办法在测试环境中绕过语言特性的限制， 尤其对遗留系统， 代码已经存在的情况. 比如对于 C++ 中的 static 函数， 可以将整个被测单元 #include， 或者 #define static 为空. 宏代表了一层间接， 在测试环境中， 这层间接是至关重要的. 其它方法可参考 <<Working Effectively with Legacy Code>>， <<假冒的艺术>>中的介绍.

　　Q: 刚才提到了要支持"测试"而不是"Debug"， 测试和Debug难道有什么矛盾吗?

　　A: 有. 如果你发现不得不 Debug， 是测试粒度太粗， 步子迈的太大， 产品代码过长等导致的， 甚至可能你卷入了过多的单元而破坏了测试的隔离性. Debug还是代码逻辑不清， 行为难以断言的表现.  用测试帮你定位错误.

　　Q: 我知道为遗留系统增加新特性是要先写测试保证系统原来的行为， 可遗留代码很庞大， 我甚至都不知道系统目前的行为， 怎么办?

　　A: 特征测试: 保持代码行为的测试， 获取当前运行结果， 来填充测试， 以获取系统目前行为. 其实测试可以分为两类: 试图说明想要实现的目标， 或者试图保持代码中既有的行为; 在特性实现后， 前者会转化为后者. 详细信息请参见<<Working Effectively with Legacy Code>>

　　Q: 前面经常说到 C++ 或其它面向对象语言， 却没有提到 C， 那么过程式语言中如何应用 TDD ? 有什么不一样?

　　A: 基本一样， 并且在过程式语言中应用 TDD， 可能会导出面向对象风格的设计. 比如如果直接调用某个函数， 那么不得不通过编译时替换或链接时替换来接入假的实现. 这样其实比较麻烦， 因此可能会促使你选用函数指针 ，以便方便的在测试环境中进行替换. 随着时间的推移， 你会发现一组组概念相关的函数指针出现了， 那么把它们和它们操作的数据绑定在一起， 定义一个 struct， 形成了一种对象风格. 当然这反而可能会令你的代码更复杂， 这需要在实践中取舍.

　　也有可能在过程式语言中你觉得 TDD 对设计的促进不大， 而且测试用例也比较枯燥， 是测个分支， 返回值什么的. 是的， 逻辑隐藏在分支和返回值中， 如果习惯了过程式思维并不打算改变， TDD 对设计的影响则更多的体现在依赖管理上， 如头文件和编译单元的职责划分. 如果把不同职责的函数混在一个编译单元里面， 则很难实施链接替换等手段， 除非你选择一个类似 mockcpp 的框架， 不需要链接替换.

　　Q: 如果使用 TDD， 那么测试人员怎么安排? 是不是一开始要进入项目组? 可那时还没有产品代码，测什么?

　　A: 是， 是一开始要进入项目组， 可不是因为 TDD.  是， 测试人员是一开始没什么可测的， 可不代表没活干.

　　TDD是一种开发方法， 是开发人员参与的活动. 其效果是以可执行的形式文档化你的需求， 迫使你分清职责隔离依赖以驱动你的设计， 编织安全网以扼杀Bug在摇篮状态防止逃逸. 可传统测试人员的活动是试图找到已经逃逸的Bug. 这两种活动都是必要的， 而且毫不冲突， 互为补充.

　　那么测试人员在新的特性还没开发完成之前做什么呢? 除了提前写测试用例， 无论是自动化的还是非自动化的， 而需要测试人员参加的一项重要活动， 是参与特性验收条件的制定. 之前经常发生开发人员按照自己的理解去编码， 测试人员按照自己的理解去测试， 直到开发完成， 测试过程中才发现理解的不一致， 开始产生争执并阻塞等待业务分析人员(如果幸运的话)或者行政主管(如果开发过程混乱的话)的仲裁. 解决办法是在开始开发新特性前的一刹那， 由业务分析人员， 测试人员， 开发人员进行一次讨论， 验收条件达成一致并形成记录， 然后测试人员和开发人员分头去写测试和实现.