Mock服务实现的几种思路（持续更新）

一、直接对三方的Mock

这种方式其实也是最简单的方式，搭建一个spring工程，实现对对应接口的模拟。采用postman等工具其实也可以实现简单的对三方模拟，最好的方式是返回结果可以写在数据库中，本质就是根据请求的参数返回指定的结果。

几种常用方式：保证数据库值的有效性，信息扭转过程中的有效性。

• 参数来自数据库
• 值来自数据库
• 请求原代码中的接口等等

二、接口但是涉及到落库

其实在很多自动化代码中也会遇见过类似场景，通常实现方式无非对数据的操作与服务代码的调用。

三、RPC服务相关

通过filter拦截，在方法做切面时设置参数

切面参数用到ThreadLocal（做线程参数的副本）
用到
比如对接理财银行产品接入：

• 每家银行的数据类型不相同，因此对接不同银行要做数据适配
• 涉及到如trade、assert、account、bridge等等服务，最外层可以采用bridge进行统一封装对接
• 每一次请求如一个线程，所以可以对线程赋值，采用ThreadLocal统一管理（保存线程中值的副本，相互请求资源隔离）
• 底层操作，不涉及银行方面，则可以采用统一的服务，如账户管理、交易管理、资产付息管理等等
• 所以整体mock可以考虑在bridge层展开。

在bridge展开过程中

• 建立一个元素切面如：ParamCacheAspect，保存如渠道Supplier、方法Method、名字name
• 在通过供应商路由：XXXAccountFacade
• XXXApiManage
• 到invoke的动态代理
• 通过SOFA Filter的过滤器 SOFAPRC Filter
• 根据配置内容，执行不同操作

MOCK常用场景

1、无法控制第三方系统某接口的返回，返回的数据不满足要求
比如：支付中最常用的刷卡支付，有可能直接支付成功，也有可能返回支付中，此逻辑受平台方风控逻辑校验，对我们来说完全是黑盒子

2、某依赖系统还未开发完成，就需要对被测系统进行测试
前端开发比较依赖后端开发提供的接口，然后根据接口返回值设计各类场景页面。当服务端开发人员未及时提供接口时可能会影响到前端开发及整个项目的进度，特别是在敏捷开发中，对于上下游开发顺序更加依赖

3、有些系统不支持重复请求，如支付功能

4、系统功能有访问频次限制，获取敏感信息的接口访问频次不可高于xx等

参考：

https://www.jianshu.com/p/4afa11356662