JUnit与Spring的整合——JUnit的TestCase如何自动注入Spring容器托管的对象

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: JUnit与Spring的整合——JUnit的TestCase如何自动注入Spring容器托管的对象 问题 在Java中,一般使用JUnit作为单元测试框架,测试的对象一般是Service和DAO,也可能是RemoteService和Controller。

JUnit与Spring的整合——JUnit的TestCase如何自动注入Spring容器托管的对象

问题

在Java中,一般使用JUnit作为单元测试框架,测试的对象一般是Service和DAO,也可能是RemoteService和Controller。所有这些测试对象基本都是Spring托管的,不会直接new出来。而每个TestCase类却是由JUnit创建的。如何在每个TestCase实例中注入这些依赖呢?

预期效果

我们希望能够达到这样的效果:

package me.arganzheng.study;
import static org.junit.Assert.*;
import org.junit.Test;
import org.springframework.beans.factory.annotation.Autowired;
/**
 * @author arganzheng
 */
public class FooServiceTest{
    @Autowired
    private FooService fooService;
    @Test
    public void testSaveFoo() {
        Foo foo = new Foo();
        // ...
        long id = fooService.saveFoo(foo);
        assertTrue(id > 0);
    }
}

解决思路

其实在我前面的文章:Quartz与Spring的整合-Quartz中的job如何自动注入spring容器托管的对象,已经详细的讨论过这个问题了。Quartz是一个框架,Junit同样是个框架,Spring对于接入外部框架,采用了非常一致的做法。对于依赖注入,不外乎就是这个步骤:

  1. 首先,找到外部框架创建实例的地方(类或者接口),比如Quartz的jobFactory,默认为org.quartz.simpl.SimpleJobFactory,也可以配置为org.quartz.simpl.PropertySettingJobFactory。这两个类都是实现了org.quartz.spi.JobFactory接口。对于JUnit4.5+,则是org.junit.runners.BlockJUnit4ClassRunner类中的createTest方法。
     /**
      * Returns a new fixture for running a test. Default implementation executes
      * the test class's no-argument constructor (validation should have ensured
      * one exists).
      */
     protected Object createTest() throws Exception {
         return getTestClass().getOnlyConstructor().newInstance();
     }
  2. 继承或者组合这些框架类,如果需要使用他们封装的一些方法的话。如果这些类是有实现接口的,那么也可以直接实现接口,与他们并行。然后对创建出来的对象进行依赖注入。

比如在Quartz中,Spring采用的是直接实现org.quartz.spi.JobFactory接口的方式:

    public class SpringBeanJobFactory extends AdaptableJobFactory implements SchedulerContextAware {
        ...
    }
    public class AdaptableJobFactory implements JobFactory {
        ...
    }

但是Spring提供的org.springframework.scheduling.quartz.SpringBeanJobFactory并没有自动依赖注入,它其实也是简单的根据job类名直接创建类:

    /**
     * Create an instance of the specified job class.
     * <p>Can be overridden to post-process the job instance.
     * @param bundle the TriggerFiredBundle from which the JobDetail
     * and other info relating to the trigger firing can be obtained
     * @return the job instance
     * @throws Exception if job instantiation failed
     */
    protected Object createJobInstance(TriggerFiredBundle bundle) throws Exception {
        return bundle.getJobDetail().getJobClass().newInstance();
    }

不过正如它注释所说的,Can be overridden to post-process the job instance,我们的做法也正是继承了org.springframework.scheduling.quartz.SpringBeanJobFactory,然后覆盖它的这个方法:

public class OurSpringBeanJobFactory extends org.springframework.scheduling.quartz.SpringBeanJobFactory{
    @Autowire
    private AutowireCapableBeanFactory beanFactory;
    /**
     * 这里我们覆盖了super的createJobInstance方法,对其创建出来的类再进行autowire。
     */
    @Override
    protected Object createJobInstance(TriggerFiredBundle bundle) throws Exception {
        Object jobInstance = super.createJobInstance(bundle);
        beanFactory.autowireBean(jobInstance);
        return jobInstance;
    }

由于OurSpringBeanJobFactory是配置在Spring容器中,默认就具备拿到ApplicationContext的能力。当然就可以做ApplicationContext能够做的任何事情。

题外话

这里体现了框架设计一个很重要的原则:开闭原则——针对修改关闭,针对扩展开放。
除非是bug,否者框架的源码不会直接拿来修改,但是对于功能性的个性化需求,框架应该允许用户进行扩展。
这也是为什么所有的框架基本都是面向接口和多态实现的,并且支持应用通过配置项注册自定义实现类,
比如Quartz`org.quartz.scheduler.jobFactory.class``org.quartz.scheduler.instanceIdGenerator.class`配置项。

解决方案

回到JUnit,其实也是如此。

Junit4.5+是通过org.junit.runners.BlockJUnit4ClassRunner中的createTest方法来创建单元测试类对象的。

/**
 * Returns a new fixture for running a test. Default implementation executes
 * the test class's no-argument constructor (validation should have ensured
 * one exists).
 */
protected Object createTest() throws Exception {
   return getTestClass().getOnlyConstructor().newInstance();
}

那么根据前面的讨论,我们只要extendsorg.junit.runners.BlockJUnit4ClassRunner类,覆盖它的createTest方法就可以了。如果我们的这个类能够方便的拿到ApplicationContext(这个其实很简单,比如使用ClassPathXmlApplicationContext),那么就可以很方便的实现依赖注入功能了。JUnit没有专门定义创建UT实例的接口,但是它提供了@RunWith的注解,可以让我们指定我们自定义的ClassRunner。于是,解决方案就出来了。

Spring内建的解决方案

Spring3提供了SpringJUnit4ClassRunner基类让我们可以很方便的接入JUnit4。

public class org.springframework.test.context.junit4.SpringJUnit4ClassRunner extends org.junit.runners.BlockJUnit4ClassRunner {
    ...
}

思路跟我们上面讨论的一样,不过它采用了更灵活的设计:

  1. 引入Spring TestContext Framework,允许接入不同的UT框架(如JUnit3.8-,JUnit4.5+,TestNG,etc.).
  2. 相对于ApplicationContextAware接口,它允许指定要加载的配置文件位置,实现更细粒度的控制,同时缓存application context per Test Feature。这个是通过@ContextConfiguration注解暴露给用户的。(其实由于SpringJUnit4ClassRunner是由JUnit创建而不是Spring创建的,所以这里ApplicationContextAware should not work。但是笔者发现AbstractJUnit38SpringContextTests是实现ApplicationContextAware接口的,但是其ApplicationContext又是通过org.springframework.test.context.support.DependencyInjectionTestExecutionListener加载的。感觉实在没有必要实现ApplicationContextAware接口。)
  3. 基于事件监听机制(the listener-based test context framework),并且允许用户自定义事件监听器,通过@TestExecutionListeners注解注册。默认是org.springframework.test.context.support.DependencyInjectionTestExecutionListenerorg.springframework.test.context.support.DirtiesContextTestExecutionListenerorg.springframework.test.context.transaction.TransactionalTestExecutionListener这三个事件监听器。

其中依赖注入就是在org.springframework.test.context.support.DependencyInjectionTestExecutionListener完成的:

/**
 * Performs dependency injection and bean initialization for the supplied
 * {@link TestContext} as described in
 * {@link #prepareTestInstance(TestContext) prepareTestInstance()}.
 * <p>The {@link #REINJECT_DEPENDENCIES_ATTRIBUTE} will be subsequently removed
 * from the test context, regardless of its value.
 * @param testContext the test context for which dependency injection should
 * be performed (never <code>null</code>)
 * @throws Exception allows any exception to propagate
 * @see #prepareTestInstance(TestContext)
 * @see #beforeTestMethod(TestContext)
 */
protected void injectDependencies(final TestContext testContext) throws Exception {
    Object bean = testContext.getTestInstance();
    AutowireCapableBeanFactory beanFactory = testContext.getApplicationContext().getAutowireCapableBeanFactory();
    beanFactory.autowireBeanProperties(bean, AutowireCapableBeanFactory.AUTOWIRE_NO, false);
    beanFactory.initializeBean(bean, testContext.getTestClass().getName());
    testContext.removeAttribute(REINJECT_DEPENDENCIES_ATTRIBUTE);
}

这里面ApplicationContext在Test类创建的时候就已经根据@ContextLocation标注的位置加载存放到TestContext中了:

/**
 * TestContext encapsulates the context in which a test is executed, agnostic of
 * the actual testing framework in use.
 * 
 * @author Sam Brannen
 * @author Juergen Hoeller
 * @since 2.5
 */
public class TestContext extends AttributeAccessorSupport {
    TestContext(Class<?> testClass, ContextCache contextCache, String defaultContextLoaderClassName) {
        ...
        if (!StringUtils.hasText(defaultContextLoaderClassName)) {
            defaultContextLoaderClassName = STANDARD_DEFAULT_CONTEXT_LOADER_CLASS_NAME;
        }
        ContextConfiguration contextConfiguration = testClass.getAnnotation(ContextConfiguration.class);
        String[] locations = null;
        ContextLoader contextLoader = null;
        ...
        Class<? extends ContextLoader> contextLoaderClass = retrieveContextLoaderClass(testClass,
            defaultContextLoaderClassName);
        contextLoader = (ContextLoader) BeanUtils.instantiateClass(contextLoaderClass);
        locations = retrieveContextLocations(contextLoader, testClass);
        this.testClass = testClass;
        this.contextCache = contextCache;
        this.contextLoader = contextLoader;
        this.locations = locations;
    }
}

说明 :

Spring3使用了Spring TestContext Framework框架,支持多种接入方式:10.3.5.5 TestContext support classes。非常不错的官方文档,强烈推荐阅读。简单概括如下:

  • JUnit3.8:package org.springframework.test.context.junit38
    • AbstractJUnit38SpringContextTests
      • applicationContext
    • AbstractTransactionalJUnit38SpringContextTests
      • applicationContext
      • simpleJdbcTemplate
  • JUnit4.5:package org.springframework.test.context.junit4
    • AbstractJUnit4SpringContextTests
      • applicationContext
    • AbstractTransactionalJUnit4SpringContextTests
      • applicationContext
      • simpleJdbcTemplate
    • Custom JUnit 4.5 Runner:SpringJUnit4ClassRunner
      • @Runwith
      • @ContextConfiguration
      • @TestExecutionListeners
  • TestNG: package org.springframework.test.context.testng
    • AbstractTestNGSpringContextTests
      • applicationContext
    • AbstractTransactionalTestNGSpringContextTests
      • applicationContext
      • simpleJdbcTemplate

补充:对于JUnit3,Spring2.x原来提供了三种接入方式:

  • AbstractDependencyInjectionSpringContextTests
  • AbstractTransactionalSpringContextTests
  • AbstractTransactionalDataSourceSpringContextTests

不过从Spring3.0开始,这些了类都被org.springframework.test.context.junit38.AbstractJUnit38SpringContextTestsAbstractTransactionalJUnit38SpringContextTests取代了:

@deprecated as of Spring 3.0, in favor of using the listener-based test context framework(不过由于JUnit3.x不支持beforeTestClassafterTestClass,所以这两个事件是无法监听的。)

({@link org.springframework.test.context.junit38.AbstractJUnit38SpringContextTests})


采用Spring3.x提供的SpringJUnit4ClassRunner接入方式,我们可以这样写我们的UT:

package me.arganzheng.study;
import static org.junit.Assert.*;
import org.junit.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
/** 
 * @author arganzheng
 */
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({
    "classpath:conf-spring/spring-dao.xml",
    "classpath:conf-spring/spring-service.xml",
    "classpath:conf-spring/spring-controller.xml"
})
public class FooServiceTest{
    @Autowired
    private FooService fooService;
    @Test
    public void testSaveFoo() {
        Foo foo = new Foo();
        // ...
        long id = fooService.saveFoo(foo);
        assertTrue(id > 0);
    }
}

当然,每个UT类都要配置这么多anotation配置是很不方便的,搞成一个基类会好很多:

ackage me.arganzheng.study;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.transaction.annotation.Transactional;    
/**  
 * @author arganzheng
 */
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({
    "classpath:conf-spring/spring-dao.xml",
    "classpath:conf-spring/spring-service.xml",
    "classpath:conf-spring/spring-controller.xml"
})
@Transactional
public class BaseSpringTestCase{
}

然后我们的FooServiceTest就可以简化为:

package me.arganzheng.study;
import static org.junit.Assert.*;
import org.junit.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.annotation.Rollback;
/** 
 * @author arganzheng
 */
public class FooServiceTest extends BaseSpringTestCase{
    @Autowired
    private FooService fooService;
    @Test
    // @Rollback(true) 默认就是true
    public void testSaveFoo() {
        Foo foo = new Foo();
        // ...
        long id = fooService.saveFoo(foo);
        assertTrue(id > 0);
    }
}

单元测试的其他问题

上面只是简单解决了依赖注入问题,其实单元测试还有很多。如

  1. 事务管理
  2. Mock掉外界依赖
  3. web层测试
  4. 接口测试
  5. 静态和私有方法测试
  6. 测试数据准备和结果验证

等等。

--EOF--

原文地址http://www.bieryun.com/2033.html

相关文章
|
6天前
|
XML Java 数据格式
Spring容器Bean之XML配置方式
通过对以上内容的掌握,开发人员可以灵活地使用Spring的XML配置方式来管理应用程序的Bean,提高代码的模块化和可维护性。
33 6
|
21天前
|
安全 Java 开发者
Spring容器中的bean是线程安全的吗?
Spring容器中的bean默认为单例模式,多线程环境下若操作共享成员变量,易引发线程安全问题。Spring未对单例bean做线程安全处理,需开发者自行解决。通常,Spring bean(如Controller、Service、Dao)无状态变化,故多为线程安全。若涉及线程安全问题,可通过编码或设置bean作用域为prototype解决。
32 1
|
1月前
|
前端开发 Java Docker
使用Docker容器化部署Spring Boot应用程序
使用Docker容器化部署Spring Boot应用程序
|
1月前
|
Java Docker 微服务
利用Docker容器化部署Spring Boot应用
利用Docker容器化部署Spring Boot应用
51 0
|
2月前
|
Java 测试技术 Windows
咦!Spring容器里为什么没有我需要的Bean?
【10月更文挑战第11天】项目经理给小菜分配了一个紧急需求,小菜迅速搭建了一个SpringBoot项目并完成了开发。然而,启动测试时发现接口404,原因是控制器包不在默认扫描路径下。通过配置`@ComponentScan`的`basePackages`字段,解决了问题。总结:`@SpringBootApplication`默认只扫描当前包下的组件,需要扫描其他包时需配置`@ComponentScan`。
|
16天前
|
监控 NoSQL 时序数据库
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
155 77
|
25天前
|
监控 Docker 容器
在Docker容器中运行打包好的应用程序
在Docker容器中运行打包好的应用程序
|
3天前
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
27 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
9天前
|
关系型数据库 应用服务中间件 PHP
实战~如何组织一个多容器项目docker-compose
本文介绍了如何使用Docker搭建Nginx、PHP和MySQL的环境。首先启动Nginx容器并查看IP地址,接着启动Alpine容器并安装curl测试连通性。通过`--link`方式或`docker-compose`配置文件实现服务间的通信。最后展示了Nginx配置文件和PHP代码示例,验证了各服务的正常运行。
29 3
实战~如何组织一个多容器项目docker-compose
|
18天前
|
数据建模 应用服务中间件 nginx
docker替换宿主与容器的映射端口和文件路径
通过正确配置 Docker 的端口和文件路径映射,可以有效地管理容器化应用程序,确保其高效运行和数据持久性。在生产环境中,动态替换映射配置有助于灵活应对各种需求变化。以上方法和步骤提供了一种可靠且易于操作的方案,帮助您轻松管理 Docker 容器的端口和路径映射。
60 3