测试问题域: Test Double, 以及为什么Mock之争都争错了方向 - 切尔斯基 - 博客频道 - CSDN.NET http://blog.csdn.net/chelsea/article/details/7176479

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

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