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

821 阅读5分钟

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

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

前端依赖后端接口

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

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

YAPI: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 框架, 地址:github.com/mockito/moc…

在单测的时候,可以用 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微服务 入门 实战与进阶》作者, 公众号猿天地发起人。