Thinking Twice Before Using @Moc

作者: aikin | 来源:发表于2018-04-01 22:37 被阅读193次

    号外!号外!号外!你的 spring boot integration tests 运行慢吗,是不是每跑一次测试,你都在等待,等待它全绿的那一瞬间。如果你遇到,那请接着往下看,也许可以帮助到你。如果你没有遇到,那也请往下看,因为也许以后你会遇到。

    告诉你一个秘密:@MockBean会导致测试类(Test Class)之间spring boot application context不断启动多次!!!

    不信,那么我们请看栗子 MockBean Annotation:

    这项目有两个测试类,AboutControllerTestTokenControllerTest

    AccountControllerTest:

    account-controller.png

    TokenControllerTest:

    token-controller.png

    AccountControllerTest 没有使用 @MockBeanTokenControllerTest 使用 @MockBean。下面是两个测试一起运行产生的日志:

    spring-boot-log.png

    如上图所示,spring boot 启动两次。而spring boot 的启动时间也比较耗时,所以@MockBean,很有可能导致测试运行的很慢。那@MockBean到底是个怎么样的存在?

    WHAT

    写过spring boot integration test的小伙伴,对于@MockBean应该会比较熟悉。在写测试时,对于一些应用的外部依赖需要进行一些Mock 处理,比如:RedisElasticSearchExternalService 等。官方文档介绍 Mocking and spying beans

    mock-bean.png
    • It allows to add Mockito mocks in a Spring ApplicationContext.
    • If a bean, compatible with the declared class exists in the context, it replaces it by the mock.
    • If it is not the case, it adds the mock in the context as a bean.

    也就是说,@MockBean会改变spring boot application context beans,导致使用了@MockBean的测试类之间的需要不同application context,从而导致spring boot application context重启。为什么需要不同application context 就需要重启???带着疑惑,我们接着往下看。

    WHY

    Spring Boot Application Context

    什么是application context?简单理解,就是应用程序运行所需要的上下文。官方文档介绍 Context Management:

    context-management.png

    官方文档介绍 Context management and caching

    testing-ctx-management.png

    根据官方文档意思,application context为初始化测试实例提供上下文,如果需要不同的application context实例化不同的测试,就需要重新启动spring boot,创建不同applicaiton context。文档还说到,为了解决spring boot application context启动慢的问题,会做缓存处理。那@MockBean到底破坏了什么样的缓存规则,从而导致spring boot重启多次?是什么导致打开方式出了问题?

    Spring Boot Application Context Cache

    要回答这个问题,就要先了解[application context caching]的uniquely key包含的内容,附上官方文档介绍 Context caching

    context-caching.png

    根据文档的描述,不难知道application context cacheing是通过key:value方式进行缓存的,唯一键为组合键,包含:locations、classes、contextInitializerClasses、contextCustomizers、contextLoader、parent、activeProfiles、propertySourceLocations、propertySourceProperties、resourceBasePath

    @MockBean的使用会导致每个application contextcontextCustomizer的不同,从而导致存储在context cache中的application contextuniquely key不同,最终导致application context在测试类之间不能共享。虽然没有官方文档说明这一点,不过在
    org.springframework.boot.test.mock.mockito.MockitoContextCustomizerFactory 源代码中可以找到一些痕迹:

    mock-customizer.png

    图中所说的MergedContextConfiguration就是application context cachinguniquely key

    HOW

    对于spring boot integration test 来说,除了 external service(clients...) 需要被 Mock,其它的内部依赖(service、repository…)都不应该被Mockexternal service 可以在配置层,进行Mock,然后在测试类中,直接通过@Auotwrite方式注入:

    RedisTemplateBeanConfigurationMocker

    redis-configuration-mocker.png

    RedisConfiguration

    redis-configuration.png

    TokenControllerTest:

    token-controller-fixed.png

    TokenControllerTest,直接 @Autowrite RedisTemplateBeanConfigurationMocker 中配置的,RedisTemplate @Bean。完成栗子,请查mockbean-annotation

    写在最后

    spring boot integration test 相对于 api test,应该更关注api功能的完整性,了解依赖的边界,不需要Mock的,就不要Mock,比如:service, repository…。对于外部依赖,统一在配置层完成 Mock,比如:client、redis、rabbitmq...

    原文链接

    相关文章

      网友评论

        本文标题:Thinking Twice Before Using @Moc

        本文链接:https://www.haomeiwen.com/subject/arqzcftx.html