Q: 我原来的测试都是用真实的代码来跑， 一个测试能覆盖多个单元. 你现在都把依赖替换掉了， 那被替换掉的模块有问题怎么办? 怎么保证集成真实的代码后还能正确工作?

　　A: 其它单元有其它单元自己的单元测试， 各自关注自己. 集成测试像以前一样， 该怎么测还怎么测， 并不是有了单元测试不要其它测试了.

　　Q: 单元测试是设计? 单元测试怎么能反映/代替设计 ?

　　A: 单元测试反映的是局部的设计， 局限于本单元以及与之交互的其它单元. 前面说的单元测试能够反映系统的其它部分对当前单元的需求， 所谓设计是单元之间的职责划分， 交互和依赖关系

　　当你试图测试一个单元时， 却发现需要创建大量的其它对象， 而且按照你脑海中的实现， 有些对象是在单元内部创建的， 根本无法在测试环境中假冒它们. 这时候， 你即使只是为了减少测试的难度， 也会逼迫自己思考:

　　这个单元是否做了太多的事， 承担了额外的职责， 违反了单一职责原则?

　　是否应该把依赖让外界设置进来， 而不是自己在内部创建， 这样测试时能把依赖设置为假冒的实现?

　　是的， 单元测试警示你思考一下自己的设计

　　Q: 单元测试是设计， 还有人说源代码是设计， 到底是测试是设计还是源代码是设计?

　　A: 这实际上是另外一种角度. 源代码是设计的论断基于两个假设

　　设计阶段中工程师的工作产物， 也是他的设计， 是应该能够在实施阶段被不同的实施者严格并且几乎一模一样的实现

　　软件开发人员也是工程师， 即软件工程师

　　如果我们认同这两个假设， 那么软件工程师的什么产物能够被严格并且重复实现的呢? 是你的Word形式的"设计"文档吗? 是CAD工具画出的UML图吗? 都不是， 因为它们都不精确， 有无数种实现方式， 根本谈不到严格， 不同的开发人员会有完全不同的实现. 事实上， 只有源代码，才能满足这个约束. 这样软件的设计阶段， 是直到软件工程师完成源代码的那一刻， 而软件的实施阶段， 其实只剩编译和部署了. 跑题了.

　　Q: 单元测试是需求"文档"， 单元测试又是设计"文档"， 它怎么能既是需求又是设计呢?

　　A: 名字和断言描述需求， 环境设置描述设计 ...

　　Q: 既然单元测试描述的是需求， 它应该是黑盒测试了? 可单元测试不一直都被认为是白盒测试吗?

　　A: 黑白都是相对于你观察的层次. 相对于其它从外部观察"系统"行为， 不涉及源代码的测试来说， 单元测试深入到内部观察盒子的行为， 所以是白盒. 而具体到每个单元测试用例， 依然在尽可能的从外部观察"单元"的行为， 所以又是黑盒.

　　Q: 但是你们常用的 Mock 技术， 明显把单元测试推向白盒的境地.

　　A: 说来话长， 但可以先说结论: 基于状态的测试 over 基于交互/行为的测试， 虽然右边的也有巨大的价值， 但我们认为左边的更稳定和更富有对系统的洞察力

　　基于状态的测试描述的是需求， 基于交互行为的测试描述的是实现. 相对于需求来说， 实现更易发生变化， 尤其在另外一种实践"重构"的冲击下， 描述实现的测试将被修改的面目全非， 带来相当的返工和维护成本

　　一种例外， 是交互本身是需求， 这时 mock 是合适的选择. 一个杜撰的例子参见<<TDD: Tricky Driven Design 3， 方法>>中后银行API的例子

　　而现实生活中， 存在一些情况， 虽然使用 mock 可能带来后期的维护成本， 但它带来的好处也是不可代替的. 比如对先期整体测试代码的编码量的降低. 这在 C/C++ 项目中尤其明显:

　　受限于C/C++的编译模型， 使用常用的预处理期接入点和编译链接接入点技术来接入 stub 实现时， 要小心维护头文件的防卫宏， 头文件的名称， 不同环境下构建脚本的include路径设置， 库路径设置等. 手工写stub的方式变的及其繁琐和容易出错. 这时候， 一个易用的 mock 框架如 mockcpp 等将节省大量的编码和先期维护工作

　　而几乎所有的mock框架， 都支持将 mock 对象退化为 stub， 如 mockcpp 中 mock 对象的 defaults() 设置， 或者 JMock 2 中的 Allowing . 事实上， 这是我推荐的 mock 使用方式: 通常情况下让它退化为简单的stub， 必要时才使用它强大的期待设置和验证能力.