微服务接口单测依赖问题一次性搞定

在微服务架构中，服务之间的依赖是很常见的事情。在开发过程中都是并行开发的，前端会依赖后端的接口，后端也有可能会依赖其他后端服务的接口。

项目整体提测后是没有问题的，因为大家都开发完了，也会同时部署到测试环境中。但是在开发过程中需要进行单测，单测的时候会依赖其他的服务，这个时候就需要解决这个依赖问题。

前端依赖后端接口

前端依赖后端接口，一般会提前将接口定义好，然后拉上前端同学一起评审。如果没有问题就各自去开发，那么前端同学在自测的时候是需要数据的，这个时候可以采用 Mock 的方式提供数据。

关于 Mock 的工具有很多，我们用的 YAPI，既可以管理接口信息，又可以提供 Mock 功能。

YAPI:https://github.com/ymfe/yapi

后端依赖其他服务接口（Dubbo）

基于预定

如果不想自己 Mock 数据，可以在一开始的时候，跟需要对接的同学约定好。接口定好后先将接口写好，返回固定的数据，发布一下。后面在慢慢开发，这样也能直接调用，并且有假数据返回。

自带 Mock 功能

Dubbo 自带了 Mock 功能，自定义一个 Mock 类，然后在使用的时候指定即可。

接口定义：

public interface UserRemoteService {
    ResponseData<UserResponse> getUser(Long userId);
}

Mock 类：

public class CustomUserRemoteServiceMock implements UserRemoteService {
    @Override
    public ResponseData<UserResponse> getUser(Long userId) {
        UserResponse userResponse = new UserResponse();
        userResponse.setNickname("尹吉欢");
        return Response.ok(userResponse);
    }
}

使用：

@Reference(version = DubboConstant.VERSION_V100,mock = "com.cxytiandi.CustomUserRemoteServiceMock")
private UserRemoteService userRemoteService;

自带的 Mock 在单测的时候其实不是很方便，因为我们调用远程服务的代码是在业务代码中，单测都是单独的代码，如果想用 Mock 还得去改动业务代码，加上 mock 的信息。很容易和本地修改的代码一起提交造成问题。

用在服务异常回退的场景还是比较适合的，返回静态数据或者缓存数据等。

包装一个类实现 Mock 功能

定义一个获取远程对象的工厂类，负责获取 Bean 的逻辑，使用者不需要关心内部逻辑。如果@Reference 注入了就返回 Dubbo 代理的 UserRemoteService。如果本地 Spring 中有对应的实现就返回本地的 UserRemoteService。

这样在单测的时候，如果对方还没有提供新服务，就可以用自己在本地建的 Mock 类实现。并且这个 Mock 类可以写在 test 包下。

@Component
public class UserRemoteServiceBeanFactory {
    @Reference(version = DubboConstant.VERSION_V100, check=false)
    private UserRemoteService userRemoteService;

    @Autowired(required = false)
    private UserRemoteService beanUserRemoteService;
    public UserRemoteService getUserRemoteService() {
        if(Objects.nonNull(beanUserRemoteService)){
            return beanUserRemoteService;
        }
        if(Objects.nonNull(userRemoteService)){
            return userRemoteService;
        }
        throw new ApplicationException("can't find UserRemoteService");
    }
}

Mocktio Mock

Mockito 就是一个优秀的用于单元测试的 Mock 框架, 地址：https://github.com/mockito/mockito

在单测的时候，可以用 Mockito Mock 出一个远程接口的实现，以及要返回的数据。

@MockBean
private UserRemoteService userRemoteService;
@Before
public void before() {
    Mockito.when(userRemoteService.getUser(1L))
            .thenAnswer(t -> {
                UserResponse userResponse = new UserResponse();
                userResponse.setNickname("mock name");
                return Response.ok(userResponse);
            });
}

上面的方式在单测的时候存在一个问题，虽然 Mock 了一个 Bean，但是业务类中还是用的 Dubbo 的代理类，所以得做一些特殊处理。

比如我们在 UserManagerImpl 中用了 UserRemoteService，那么就可以先获取 UserManagerImpl 的对象，然后在将 Mock 的 Bean set 进去，前提是得加好 setUserRemoteService 的方法。

很多时候我们在注入的时候都不会手动写 set 方法，那你也可以用反射去 set。

 UserManagerImpl userManager = applicationContext.getBean(UserManagerImpl.class);
Field field = userManager.getClass().getDeclaredField("userRemoteService");
field.setAccessible(true);
field.set(userManager, userRemoteService);

上面虽然解决了 Mock 的 Bean 可以替换的问题，但是在每个单测中都得手动去替换，这就有点受不了啊。

所以最好是单独封装一个替换的类，让使用者无感知。

@Component
public class MockitoMockDubboBeanProcessor implements BeanPostProcessor {
    @Autowired
    private ApplicationContext applicationContext;
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }
    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        if (StringUtils.isNotBlank(beanName) && !beanName.endsWith("ManagerImpl")) {
            return bean;
        }
        List<Field> fields = FieldUtils.getAllFieldsList(bean.getClass());
        for (Field field : fields) {
            processField(bean, field);
        }
        return bean;
    }
    private void processField(Object bean, Field field) {
        if (field.isAnnotationPresent(Reference.class)) {
            Map<String, ?> beans = applicationContext.getBeansOfType(field.getType());
            Optional<? extends Map.Entry<String, ?>> mockitoMock = beans.entrySet().stream()
                    .filter(b -> b.getValue().getClass().getName().contains("$MockitoMock$")).findFirst();
            if (mockitoMock.isPresent()) {
                field.setAccessible(true);
                try {
                    field.set(bean, mockitoMock.get().getValue());
                } catch (IllegalAccessException e) {
                    throw new RuntimeException(e);
                }
            }
        }
    }
}

主要还是对所有的 Bean 进行处理，然后根据你们的规范去做一些过滤。比如我这边只会在 ManagerImpl 结尾的类中去调用远程接口，那么就可以直接根据这个去过滤出来我要处理的类。

然后判断类中的属性是不是加了 Reference 注入，然后替换 Bean 为 MockitoMock 的 Bean。

后端依赖其他服务接口（Feign）

fallback

Feign 整合 Hystrix 可实现 fallback 功能，利用这个也可以实现对方服务没开发好，返回默认数据的功能。跟 Dubbo 的 Mock 类似。

Mocktio Mock

Mocktio 的方式跟上面一致，如果是 Feign 的话会更简单，因为不需要单独对类中的实例进行替换。Feign 的调用对象本来就在 Spring 中管理，Mocktio 直接就可以替换掉。

整合 YAPI

先说下想法吧，实现的话需要二次开发。比如前后端是通过 YAPI 来约定接口，前端在自测的时候也是通过 YAPI 的 Mock 功能获取 Mock 的数据。

如果用 Feign 进行远程调用，说明你们的服务内部通信就是基于 Http 方式。那么是否可以和前端一样，正常的时候走服务调用，单测的时候可以 YAPI 的 Mock 接口呢？这样也就不用自己在单测中去 Mock 数据了。

要做的话基于 Feign 底层扩展下，通过配置来控制，我这里只是给大家提供个思路，感兴趣的可以动手试试，然后投稿下，哈哈。

关于作者：尹吉欢，简单的技术爱好者，《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》作者, 公众号猿天地发起人。