测试问题域: 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在 http://www.mockobjects.com/ 的描述, Mock的思想确实起源于开发者不想仅仅为了测试就为对象加上一堆getter而破坏面向对象, 从而开发出支持对交互进行测试的技术, 但后来随着对mock技术的深入理解和mock工具的日益强大, 出现了两种变化:

• Mock不再被定位为测试依赖隔离技术, 而是被用来支持系统中角色间的接口定义: "It turns out to be less interesting as a technique for isolating tests from third-party libraries than is widely thought. Mock Objects is misnamed. It is really a technique for identifying types in a system based on the roles that objects play" (http://static.mockobjects.com/files/mockrolesnotobjects.pdf ).
• Mock工具的日益强大被用来支持一种不同的测试世界观: "系统状态是一种不必要的依赖, 只要交互正确状态一定正确, 因此我希望所有测试都以直接断言SUT(System Under Test)正确的与外部依赖进行了交互的方式来写".

第一种变化并未普及, 因为它不是一种具体的几天可以学会的技术, 而是一种经验经历相关的认知. 经验少的人需要假以时日, 而经验多的人有都有各自的观点, 软件开发毕竟不够成熟.

第二种变化导致了mock的滥用. 是的, 强大的工具容易被滥用: 我能够断言交互顺序不意味着所有的测试都需要断言顺序, 我能够断言参数不意味着所有的测试我都去断言参数. 缺乏对应用场合的识别, 缺乏对系统的洞察, 导致大量脆弱的测试. 真正重要的是识别问题, 然后选择合适的工具. Mock工具也都支持Dummy, Stub, Fake等应用场景, 不要浪费了这些功能.

　

(之前对mock的理解, 请参阅"敏捷质疑: TDD"中"但是你们常用的 Mock 技术, 明显把单元测试推向白盒的境地"那一段)