API Mocking 工具 WireMock v2 发布，包含改进的请求匹配以及 Stub 管理

API mocking 和服务虚拟化工具 WireMock v2 发布了。其中主要提升包括了改进的请求验证失败报告、可以创建自定义的请求匹配逻辑（包括使用 Java 8 lambda 表达式）、支持 gzip 请求体及响应体、随机分布的延迟（目前支持均匀分布以及对数正态分布）、cookie 及基本认证报文头的匹配。

最近作者本人 Tom Akehurst 做客 InfoQ，并解答了 WireMock v2 的新特性、服务虚拟化在现代化架构中所扮演的角色以及 mocking 和契约验证的关系等问题。

InfoQ：你好，Tom，欢迎来到 InfoQ！你能简要介绍一下自己和 WireMock 项目么？

Akehurst：大家好，我是 Tom Akehurst。白天我在伦敦的 Energized Work 帮助客户构建更好的技术，晚上（和周末）我维护着 WireMock。

我将 WireMock 描述为一个 API mocking 或服务虚拟化工具。实际上它能让你在测试时 stub 或 mock 你与所依赖的系统间的 HTTP 交互。这包含以下几个好处：

• 让你在所依赖的 API 还未完成或根本不存在时不影响自身的生产力。
• 减少对测试环境和第三方沙箱的依赖。
• 比调用真实系统进行测试更快（可能是 10 倍或更多）地运行测试案例。
• 方便地测试边界案例和故障模式，包括一些讨厌的东西如 TCP 连接断开和延迟峰值。

可以在 http://wiremock.org 上找到相关文档和其他信息。

InfoQ：你能介绍一下 WireMock 最近的 v2 发布的新特性么？

Akehurst：WireMock v2 引入了 stub 定义和请求之间“距离”的概念。这使得在报告未匹配请求和失败验证上的一些重大改进成为可能。当一个验证请求无法得到匹配，WireMock 会找到最相近的定义并显示出两者的不同。这大大减少了许多麻烦，如在测试完一个包含诸多 HTTP POST 请求的功能后，发现忘记大写一个字母。

现在扩展 API 更丰富了。响应转换可以接受参数并且可以转换代理响应。现在还可以使用自定义请求匹配逻辑，包括通过 Java 8 的 lambda 表达式。

虽然 WireMock 1.x 可以在安卓平台上运行，但这需要维护一个自己的分支并修改一些源码来绕开一些类库不兼容。多亏安卓社区一些人员的帮助，现在只需要在你的构建文件中加入几行代码就可以了。

其他记录的改变包括：

• 支持 gzip 的请求体和响应体。
• 随机分布的延迟，目前支持均匀分布以及对数正态分布。
• cookie 和基本认证报文头匹配。
• 对 stub 映射的修改、删除和（重新）保存。
• 升级到 Jetty 9，提升了性能、更少令人头痛的 Servlet API 依赖以及 bug 修复。
• 标准（standard）和独立（standalone）的 JAR 包在 Maven 仓库中成为分离的 artifact，这意味着当你只依赖于独立 JAR 包时不必再排除大片多余的依赖。

InfoQ：你认为有多少开发者意识到服务虚拟化技术（相对比于 mocking 或 stubing），并且你能分享一下 WireMock 这类工具所擅长的用例么？

Akehurst：快速看下 Google 趋势可以看到 Mockito 相比 WireMock 有大约 10 倍的搜索量。虽然有些不科学，但我认为可以说服务虚拟化的关注度要赶上对象 mock 还有一段距离。

但是对 WireMock 这类工具的兴趣在近一两年有显著的上升趋势。一个可能的解释是微服务的爆发式流行。我接触下来发现越来越多 WireMock 的用户在搭建微服务测试时使用它，不得不说这绝对是一个 WireMock 所擅长的用例。

其他 WireMock 能带来巨大价值的用例有：

• 组件测试，以接近单元测试的速度对一个独立的服务、应用进行验收测试。虽然在系统边界可以替代使用对象 mock，使用 WireMock 意味着 HTTP 客户端、资源池以及序列化反序列化都会被测试覆盖到。
• 故障案例，如 socket 断开连接。这些使用对象 mock 工具很难正确地模拟，同样地很难在真实系统中模拟。
• 隔离的性能测试，衡量单个组件的性能。虽然这里又一次可以在系统边界使用对象 mock 来替代，但是这样得出的结果很有可能是扭曲的，因为这忽略了 HTTP 客户端、连接池、线程等的影响。

InfoQ：你能分享一些使用服务虚拟化工具如 WireMock 创建测试案例的“最佳实践”么？是否有特殊的方法论可作为 WireMock 驱动测试的补充，比如行为驱动开发？

Akehurst：我在与 WireMock 用户交流和客户的工作中了解到：

• 慎重使用录制、回放功能。就如同使用 UI 自动化工具一样，录制一些定期变化的内容很快就会产生许多需要维护的工作量。
• 就像你为 UI 测试写页面对象（page objects）、围绕 stub 和验证代码写建造者（builder）和服务包装（service wrapper）一样，一开始有些费力，但是从长远来看，这会对方便维护和易读性带来收益。
• 书写故障注入测试案例，断开连接、响应 5xx 错误、增加延迟造成 socket 超时。这些不仅仅帮你找出那些生产环境中半夜三点折磨你的问题，还能帮你检查你应用的健康检测和监控是否正确工作。如果你在 JVM（或安卓）上运行，你可以以单元测试级的速度获得一个全范围的关于风险恢复能力的反馈，这绝对胜过使用 Chaos Monkey 进行测试来告诉你结果！

WireMock 与行为驱动开发工具能很好地合作。我见过也使用过的一个非常通用的模式是在一个场景的“Given”阶段配置 stub，然后在“Then”阶段进行交互的验证。

InfoQ：你怎么看待服务虚拟化和契约优先开发的关系，这两者是否有重叠部分？

Akehurst：由于我也是最近才接触这个，所以可能说得不太权威。看上去机器可读规范（如 Swagger 或 RAML）对解决检测 stub 定义与事实间偏差的问题很有前景。

另一个有意思的方法是 Spring 契约校验器（Spring Contract Verifier）所带来的，它通过契约规范来生成 WireMock 的 stub 定义，这样就可以隔离客户端进行测试了。

InfoQ：你认为像 WireMock 这类工具对非功能性需求的测试是否有用？

Akehurst：绝对有用！性能、可恢复性和安全这些都是我在使用 WireMock 进行测试和看别人测试时用到的特性。

举个例子，提出上面提到的随机延迟特性的 pull request 的是一个使用 WireMock 的团队，他们对他们微服务进行不间断的性能测试。他们的发布流程要求他们的每一个服务需要在发布到共享环境之前在隔离的环境中通过性能检测。

在可恢复性方面，有一次我在写浸泡测试案例时使用故障注入，显示了当一个第三方的系统返回代理错误时，应用在逐渐地泄漏连接池连接。

InfoQ：WireMock 网站上提到你在创建一个名字叫 MockLab 的基于 SaaS 的提案。你能和 InfoQ 读者分享一些具体细节么？

Akehurst：最近，越来越多用户提议我详细说明如何从零开始搭建 WireMock。我也看到过一些团队投入巨大工作量来部署、管理大量的 WireMock 实例，以及在上层定制 UI 来辅助探索性的测试和演示。

MockLab 的目标就是大大减少管理大量 WireMock 实例所需要的精力，用几次鼠标点击就能部署 mock 服务。这使得不懂代码的人员也可以进行测试的搭建和分析。

如果你正在搭建（或测试！）移动应用、微服务或依赖于第三方 API 的系统，我强烈推荐看一下这个项目。

如果希望了解更多或在 MockLab 可用时得到通知，请访问预发布网站： http://get.mocklab.io 。

InfoQ：Tom，谢谢你与 InfoQ 的对话。你还有什么其他想和我们读者分享的么？

Akehurst：我只想说非常感谢所有帮助过我完成发布 v2 的人。这都归功于 http://wiremock.org/about/ 所列出的人员，我要特别感谢 Sam Edwards、Rob Elliot 和 Rowan Hill，谢谢他们所付出的时间和耐心。谢谢大家！

更多关于 WireMock v2 的信息可以在项目网站找到，源码可以查看 Tom Akehurst 的 GitHub 账号。

查看英文原文： API Mocking Tool WireMock v2 Released with Improved Request Matching and Stub Management

感谢夏雪对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。