Mock技术在测试领域的应用

什么是Mock?

我想Mock这个词对于经常写单元测试的开发来说肯定不默生。如今在测试驱动开发的思想下，单元测试被推到了一个很重要的位置。因为它是直接能覆盖到所有代码逻辑的最佳测试手段。在单元测试的过程中，复杂业务逻辑需要跟外部资源通信交互，例如获得一个数据库连接对象，例如发送一个HTTP请求并获得实时回复的一些数据等等。当复杂业务从这些与外部对象的交互开始时，单元测试往往需要借助给力的Mock技术，来模拟这些外部环境和对象。最终目的是让待测试业务代码能够顺利的执行下去完成单元测试的验证。因为这样的需求，优秀的Mock单元测试框架也开始流行起来，例如MockITO、PowerMock、Mock Framework等。

Mock在测试中的作用？

Mock技术真的只能发挥在单元测试上么？在“Google如何做测试”一书中，也提到了Google使用Mock的思想，由于测试工作从项目启动之初就已经开展，许多功能代码完成的先后顺序各不相同。也许即使是同一个业务功能，在UI完成了之时，后台还没完成（或者正好相反）。那么一定要等到两者都完成并且联调完成了之后，测试工作才能展开么？试想一下开发是怎么做的：他们一定会事先约定好一个通讯格式，比如HTTP协议，后台与前端、或者后台与其他后台模块，通过HTTP协议通讯，约定好发送字段的含义和后续的逻辑，将双方的开发任务解耦合隔离开来，并行下去。等到真正联调的时，只要约定未被打破且严谨，基本上都只需要很少得时间就可以组合到一起交付给测试。

同样的思路，如果用在功能测试上，试想一下如果测试从设计之初就参与进来，他们也了解模块之间、前后台之间的通讯格式和字段的详细含义。协议的格式等等。那么也可以在测试中Mock后台、Mock前台、或者Mock业务逻辑的通讯对象。将复杂的业务逻辑测试工作都隔离开来，独立测试。当然这并不是说，不需要在真实环境中测试，但是真实的软硬件环境并不是所有情况测试都能遇见并且创造出来的、通讯协议的各种情况也不是真实环境都能遇到的，那么Mock所带来的好处就是可以全路径的来覆盖到每一种可能出现的情况。敏捷快速的随着开发的进度并行的开展测试。

举两个具体的例子吧：

1. 笔者之前负责的项目需要跟各种无线基站Radio通信，我们不可能花几百万美金去买各种类型价格不菲的基站放到实验室一台一台测试。再说就性能压力测试上也不可能真的去弄到几万台设备。所以我们的做法就是了解产品与基站通讯协议之间的详细交互格式，协议细节（SNMP），并由测试团队负责开发这样的Mock工具，在产品到真实环境去调试之前，都是使用这个Mock工具来模拟出通讯基站对象的各种数据和各种行为，从而覆盖产品的所有逻辑验证。（我们使用了基于Java的SNMP4J开源框架，并借助了几台真实基站上通讯取下来的样本数据）

2. 另外一个例子就是笔者现在的项目，需要跟PC、笔记本、服务器通讯采集并监控到它们的硬件信息。很难想象，如果不使用Mock技术每次测试的时候，我们如何去制造声卡、网卡的丢失、各种服务器内存、CPU的增加更替、如何找到大量服务器测试它们的硬件数据呈现。了解产品的通讯协议和数据格式之后，我们能隔离前后端的逻辑，利用模拟上报的数据至少能让我们专注测试前端对这些数据的展现和控制逻辑。

Mock不是银弹

测试不管是单元测试还是功能测试都可以使用Mock技术来提高效率，但正如之前在InfoQ上看到的一篇文章讲Mock技术的文章（http://www.infoq.com/cn/articles/thoughtworks-practice-partvi）提到的：Mock技术不是银弹，并非完美。我们不应该依赖它，而是应该合理的去使用和把控它才能最大程度的帮助到测试工作。

按照笔者个人的理解，如何把控使用Mock技术，至少要遵循几个前提：1. 是否了解Mock真实程度？这需要测试人员对产品的架构、通讯协议、数据格式都了如指掌。2. 拿来主义直接使用现成的Mock框架也许能快速的带来效益，但从长远观点来看，最适配每个公司产品的Mock工具，最好能由公司内部发起并维护，当然最好是测试团队来完成，因为测试人员都应该是产品的专家，这就需要他们也有不错的开发和编码、架构能力。