测试问题域: Test Double, 以及为什么Mock之争都争错了方向

全量测试又慢又难以定位错误, 其所需的测试环境的维护成本也很高. 解决方案就是化整为零分别测试. 然而引入新的问题: 测某个"部分"时所需的依赖如何满足. 解决方案是一组被称为"测试替身(Test Double)"的技术. 我们来看一下这里面具体的问题

• 为了能编译通过, 我需要依赖被满足
• 为了能正常运行, 我希望依赖的实现不要出错
• 为了覆盖到真实场景下的用例, 我需要依赖能够模拟真实场景下的行为, 并且我可以在不同的测试用例下指定不同的行为
• 在无法方便的观测系统状态变化而做出断言时, 我希望可以退而求其次, 能够得知SUT(System Under Test)正确的与外部依赖进行了交互.

解决这些问题的技术手段分别叫做Dummy, Stub, Fake, Mock等. 具体介绍可以参见xUnit Test Patterns. 这些技术对SUT的要求就是其能针对接口进行编程, 以避免Test Double的实现技术过于复杂和困难. 而通常这几种Test Double都可以通过手工编写实现某个接口的替身类来完成.

于是这里引入了新的问题: 手工编写替身类太繁琐了, 体力劳动, 重复代码, 大量的测试用例要求大量的替身类. 尤其是测试交互的那些替身类, 要能够记录和断言传入的参数, 调用顺序等. 为解决这些问题需要对替身类进行设计. 而人们发现主流语言Java, C#等提供的语言特性可以动态的生成这些替身类, 简化手工操作和代码量. 于是这类工具被制造出来, 称为mock工具.

换言之, mock工具解决的不是测试中的依赖问题, 而是实现依赖的测试替身手工维护成本太高的问题. (只不过其中对"如何测试交互"那部分的支持被称为mock对象而已)

-------------现实的分隔线---------------

上面的说法只是对历史的一厢情愿的解读. 虽然根据Steve Freeman在