背景动机

某期优化需要针对通用的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上转一圈，找到了以下几篇关联性较强的文章(仓库)：

从微服务下的契约测试(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 。