zoukankan      html  css  js  c++  java
  • 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管理平台,这种平台很多,国内的类似小幺鸡YApiRap2Eolinker。但这些平台都必须是作为独立进程部署,而作为单元测试场景,我需要的足够轻量的部署方式。
    照例先google、baidu、stackoverflow、github、mvnrepository上转一圈,找到了以下几篇关联性较强的文章(仓库):

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

    根据文章推荐,筛选出mock-serverokhttp/mockwebserverWireMock

    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最弱,WireMockmock-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-serverWireMock都能满足你。

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

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

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

  • 相关阅读:
    cnpm镜像安装
    wxParse解析html
    C++回调函数
    QT源码分析:QTcpServer
    QT实现支持加密的Sqlite数据库引擎
    VS2013+OpenCV3.4.2编译
    Android Tcp操作
    使用Delphi开发linux应用
    QT5.10+MinGW+OpenCV3.4.2编译
    C++ ActiveX开发的问题讨论
  • 原文地址:https://www.cnblogs.com/larva-zhh/p/11678940.html
Copyright © 2011-2022 走看看