测试问题域: 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,Fake等应用场景,不要浪费了这些功能.

　

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