Java单元测试 Http Server Mock框架选型

背景动机

某期优化需要针对通用的HttpClient封装组件--HttpExecutor在保证上层暴露API不动的前提做较多改动，大致包括以下几点：

• apache http client 版本升级
• HttpClientBuilder代码重构
• RequestBuilder代码重构
• 自定义RetryHandler
• HttpContext扩展
• 自定义HttpRequestInterceptor/HttpResponseInterceptor

代码很快修改完了，但是如何保证HttpExecutor的行为和以前是一致的呢？很容易就想到是单元测试。因为以前的代码并未提供组件的单元测试，都是依赖QA同学的黑盒测试完成，现有的单元测试又都是在更上层的HttpDao上，重点是对返回数据的解析逻辑代码验证，直接Mock了HttpExecutor的返回结果，完全无法覆盖底层组件的请求逻辑，因此配合本期优化需要提供HttpExecutor组件的单元测试。

需求分析

先大致分析一下HttpExecutor组件提供的功能：

• 注册apache http client实例的初始化和销毁，包含ConnectionManager等apache http client子功能组件；
• 上层入参的转封装，以及HttpResponse结果的初步解析封装（response header、status code、response data）；
• 依赖Interceptor对Http请求进行简单的统计；
• 指定IO异常时的重试功能；

从功能上来分析，我需要的框架/组件需要满足以下功能：

1. 响应延时；
2. 异常模拟；
3. Response Mock；
4. request verify（请求验证）；
5. 必须是通过server simulate的方式，而非client stub，即必须真实的发起Http请求；
6. 足够轻量，不必通过独立进程部署；

作为加分项，最好可以提供以下功能：

1. Record & Replay（记录真实请求自动生成回放配置，生写代码有点痛苦）；
2. 支持json或yaml等非代码的DSL配置方式；
3. 和Junit等单元测试框架集成良好；
4. 支持maven plugin；
5. 支持版本控制；

选型

从需求分析中必须真实发起请求来看，我的目标就是类似前后端分离开发中常用的API管理平台，这种平台很多，国内的类似小幺鸡、YApi、Rap2、Eolinker。但这些平台都必须是作为独立进程部署，而作为单元测试场景，我需要的足够轻量的部署方式。
照例先google、baidu、stackoverflow、github、mvnrepository上转一圈，找到了以下几篇关联性较强的文章(仓库)：

• Introduction to MockServer
• Introduction to WireMock
• okhttp/mockwebserver
• Leveling Up Your UI Tests With MockWebServer
• How to mock a web server for unit testing in Java?
• API integration and mocking.Most popular frameworks
• Comparison of API simulation tools
• Compare WireMock and MockServer's popularity and activity
• npm trends：mock-api-server vs mockserver vs mockserver-node vs wiremock-js vs wiremock-standalone
• 微服务下的契约测试(CDC)解读
• Spring Cloud Contract

从微服务下的契约测试(CDC)解读中对契约测试、单元测试、接口测试区别描述中可以发现，契约测试完全能满足甚至超出我的需求，因此下面的框架选型也从契约测试的方向来出发。

根据文章推荐，筛选出mock-server、okhttp/mockwebserver、WireMock。

Framework	部署方式	抓取回放请求	代理服务模式	Https/SSL	Http2	故障模拟	多语言支持	非代码配置	生态(其他框架集成)	Http Log	Response模板
mock-server	jar包集成/独立war包部署/Maven Plugin/Node.js Module/Grunt Plugin/Docker/Kubernetes/Homebrew 等，详见Running Mock Server	支持	支持	支持	支持	支持响应延时以及500等错误响应模拟	支持多语言client（java、ruby、node）	json文件配置	-	支持	支持
okhttp/mockwebserver	jar包集成	不支持	不支持	-	支持	支持模拟慢速网络环境以及500等错误响应模拟	支持	json文件配置	OKHttp	不支持	不支持
WireMock	jar包集成/独立war包部署	支持	支持	支持	jre8版本支持	支持响应延时以及500等错误响应模拟	Node.js	json文件配置	spring-cloud-contract	支持	支持

功能特性对比

就支持的功能集来看，okhttp/mockwebserver最弱，WireMock和mock-server两者支持的特性大体相同，但是mock-server支持更多种语言和更多的部署环境，而WireMock则有Spring Cloud Contract的光环加持。

架构依赖对比

okhttp/mockwebserver本身就是OKHttp的mock组件，完全是原生的实现，除了Junit几乎没有其他依赖，是3个框架里最轻量的，详见mockwebserver/4.2.2。

mock-server使用netty作为http server，最大的依赖项就是netty，其他还有一些guava、commons-collection4、jackson等依赖，详见mockserver-core/5.6.1。

WireMock使用jetty作为http server，是典型的servlet架构，其他还依赖guava、jackson、httpclient等，详见wiremock-jre8/2.25.0。

流行度对比

google trends结果显示WireMock更流行，而npm trends的结果正好相反，npm trends上mock-server的流行度可谓完全碾压WireMock，可能和mock-server对多语言的支持以及丰富的部署环境支持有关。

总结

我们知道框架选型永远都是根据选型人员、代码现状、需求场景来决定的，因此我这里只做推荐，不说结论。

如果你只是需要简单的HTTP Server Simulator辅助业务逻辑测试，无需SSL协议支持，那我推荐你使用okhttp/mockwebserver，功能够用，十分轻量，而且是OKHttp的组件，如果是Android开发那使用正好（Android上OKHttp使用率碾压HttpClient）。

如果你已经有很多Http API在运行，希望使用Record & Replay简化Mock DSL的编写，那么mock-server和WireMock都能满足你。

如果你的测试场景包含UI/UX测试，那支持node.js的mock-server对前端开发更为友好。又或者你的真实server是netty，不想引入servlet架构。

如果你是单纯的Java API测试，并且你还使用了Spring Cloud技术栈，那么WireMock和Spring Cloud Contract是很合适的选择。

最后，附上一篇自己实现Mock Server的参考文档Using Sun Java 6 HttpServer to write a functional HTTP test 。