测试问题域: Test Double, 以及为什么Mock之争都争错了方向
全量测试又慢又难以定位错误,其所需的测试环境的维护成本也很高. 解决方案就是化整为零分别测试. 然而引入新的问题: 测某个"部分"时所需的依赖如何满足. 解决方案是一组被称为"测试替身(Test Double)"的技术. 我们来看一下这里面具体的问题
解决这些问题的技术手段分别叫做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的滥用. 是的,强大的工具容易被滥用: 我能够断言交互顺序不意味着所有的测试都需要断言顺序,我能够断言参数不意味着所有的测试我都去断言参数. 缺乏对应用场合的识别,缺乏对系统的洞察,导致大量脆弱的测试. 真正重要的是识别问题,然后选择合适的工具. Mock工具也都支持Dummy,Fake等应用场景,不要浪费了这些功能.
(之前对mock的理解,请参阅"敏捷质疑: TDD"中"但是你们常用的 Mock 技术,明显把单元测试推向白盒的境地"那一段) (编辑:安卓应用网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |