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-collection四、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 。