某期优化需要针对通用的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异常时的重试功能；
从功能上来分析，我需要的框架/组件需要满足以下功能：
- 响应延时；
- 异常模拟；
- Response Mock；
- request verify（请求验证）；
- 必须是通过server simulate的方式，而非client stub，即必须真实的发起Http请求；
- 足够轻量，不必通过独立进程部署；
作为加分项，最好可以提供以下功能：
- Record & Replay（记录真实请求自动生成回放配置，生写代码有点痛苦）；
- 支持json或yaml等非代码的DSL配置方式；
- 和Junit等单元测试框架集成良好；
- 支持maven plugin；
- 支持版本控制；
从需求分析中必须真实发起请求来看，我的目标就是类似前后端分离开发中常用的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 。