Spring 5 中文解析核心篇 - 集成测试之 TestContext(下)
###### 3.5.5 上下文管理
每个TestContext
为其负责的测试实例提供上下文管理和缓存支持。测试实例不会自动接收对配置的ApplicationContext
的访问。但是,如果测试类实现ApplicationContextAware
接口,则将对ApplicationContext
的引用提供给测试实例。请注意,AbstractJUnit4SpringContextTests
和AbstractTestNGSpringContextTests
实现了ApplicationContextAware
,因此可以自动提供对ApplicationContext
的访问。
**
@Autowired
ApplicationContext
**
>
作为实现
ApplicationContextAware
接口的替代方法,你可以通过字段或setter
方法上的@Autowired
注解为测试类注入应用程序上下文,如以下示例所示:
>
```java
@SpringJUnitConfig
class MyTest {
@Autowired //1
ApplicationContext applicationContext;
// class body...
}
```
>
1. 注入
ApplicationContext
。
>
同样,如果将测试配置为加载
WebApplicationContext
,则可以将Web应用程序上下文注入到测试中,如下所示:
>
```java
@SpringJUnitWebConfig //1
class MyWebAppTest {
@Autowired //2
WebApplicationContext wac;
// class body...
}
```
>
1. 配置
WebApplicationContext
2. 注入
WebApplicationContext
>
使用
@Autowired
的依赖关系注入是DependencyInjectionTestExecutionListener
提供的,它是默认配置的(参见测试装置的依赖注入)。
使用TestContext
框架的测试类不需要扩展任何特定的类或实现特定的接口来配置其应用程序上下文。而是通过在类级别声明@ContextConfiguration
注解来实现配置。如果你的测试类未明确声明应用程序上下文资源位置或组件类,则配置的ContextLoader
将确定如何从默认位置或默认配置类加载上下文。除了上下文资源位置和组件类之外,还可以通过应用程序上下文初始化程序配置应用程序上下文。
以下各节说明如何使用Spring的@ContextConfiguration
注解通过XML配置文件、Groovy
脚本、组件类(通常为@Configuration
类)或上下文初始化器来配置测试ApplicationContext
。另外,你可以为高级用例实现和配置自己的自定义SmartContextLoader
。
通过XML资源配置上下文
若要使用XML配置文件为测试加载ApplicationContext
,请使用@ContextConfiguration
注解测试类,并使用包含XML配置元数据的资源位置的数组配置locations
属性。简单路径或相对路径(例如context.xml
)被视为相对于定义测试类的程序包的类路径资源。以斜杠开头的路径被视为绝对类路径位置(例如:/org/example/config.xml
)。照原样使用表示资源URL的路径(即以classpath:
、file:
、http:
等开头的路径)。
将
locations
属性设置为XML文件列表。
@ContextConfiguration
通过标准Java值属性为locations
属性支持别名。因此,如果不需要在@ContextConfiguration
中声明其他属性,你可以使用以下示例中演示的格式,省略locations
属性名称的声明并声明资源位置。
不使用
location
属性指定XML文件。
如果你从@ContextConfiguration
注解中省略了位置和值属性,则TestContext
框架将尝试检测默认的XML资源位置。具体而言,GenericXmlContextLoader
和GenericXmlWebContextLoader
根据测试类的名称检测默认位置。如果你的类名为com.example.MyTest
则GenericXmlContextLoader
将classpath:com/example/MyTest-context.xml
加载应用程序上下文。以下示例显示了如何执行此操作:
从默认位置加载配置。
通过Groovy脚本配置上下文
要通过使用Groovy Bean定义DSL的Groovy脚本为测试加载ApplicationContext
,可以使用@ContextConfiguration
注解测试类,并使用包含Groovy脚本资源位置的数组配置location
或value
属性。Groovy脚本的资源查找语义与针对[XML配置文件](https://docs.spring.io/spring/docs/5.2.7.RELEASE/spring-framework-reference/testing.html#testcontext-ctx-management-xml)描述的语义相同。
激活Groovy脚本支持
>
如果类路径中有Groovy,那么就会自动启用使用Groovy脚本在Spring
TestContext
框架中加载ApplicationContext
的支持。
下面的示例显示如何指定Groovy配置文件:
如果你从@ContextConfiguration
注解中省略了location
和value
属性,则TestContext
框架将尝试检测默认的Groovy脚本。具体来说,GenericGroovyXmlContextLoader
和GenericGroovyXmlWebContextLoader
根据测试类的名称检测默认位置。如果你的类名为com.example.MyTest
则Groovy上下文加载器将从classpath:com/example/MyTestContext.groovy
加载应用程序上下文。下面的示例演示如何使用默认值:
从默认位置加载配置。
同时声明XML配置和Groovy脚本
>
你可以使用
@ContextConfiguration
的location
或value
属性同时声明XML配置文件和Groovy脚本。如果到配置的资源位置的路径以.xml
结尾,则使用XmlBeanDefinitionReader
加载该路径。否则,将使用GroovyBeanDefinitionReader
加载它。
>
以下清单显示了如何在集成测试中将两者结合起来:
>
```java
@ExtendWith(SpringExtension.class)
// ApplicationContext将从
// "/app-config.xml" 和 "/TestConfig.groovy"加载上下文
@ContextConfiguration({ "/app-config.xml", "/TestConfig.groovy" })
class MyTest {
// class body...
}
```
通过组件类配置上下文
要使用组件类(请参见基于Java的容器配置)为测试加载ApplicationContext
,可以使用@ContextConfiguration
注解测试类,并使用包含对组件类的引用的数组来配置classes
属性。以下示例显示了如何执行此操作:
指定组件类。
组件类
>
术语
组件类
可以指以下任何一种:
>
* 用
@Configuration
注解的类。* 组件(即,用
@Component
、@Service
、@Repository
或其他构造型注解注释的类)。* 与JSR-330兼容的类,该类使用
javax.inject
注解进行了注释。* 包含
@Bean
方法的任何类。* 打算注册为Spring组件的任何其他类(即
ApplicationContext
中的Spring bean),可能利用单个自动构造函数的自动装配而无需使用Spring注解。
>
有关组件类的配置和语义的更多信息,请参见@Configuration和[@Bean](https://docs.spring.io/spring-framework/docs/5.2.7.RELEASE/javadoc-api/org/springframework/context/annotation/Bean.html)的javadoc,尤其要注意
@Bean
Lite模式的讨论。
如果你从@ContextConfiguration
注解中省略了classes
属性,则TestContext
框架将尝试检测默认配置类的存在。具体来说,AnnotationConfigContextLoader
和AnnotationConfigWebContextLoader
检测到满足配置类实现要求的测试类的所有静态嵌套类,如@Configuration javadoc中所指定。请注意,配置类的名称是任意的。另外,如果需要,一个测试类可以包含多个静态嵌套配制类。在以下示例中,OrderServiceTest
类声明一个名为Config
的静态嵌套配置类,该配置类将自动用于为测试类加载ApplicationContext
:
从嵌套的Config类加载配置信息。
XML、Groovy脚本、组件类混合
有时可能需要混合使用XML配置文件、Groovy脚本和组件类(通常为@Configuration
类)来为测试配置ApplicationContext
。如果在生产中使用XML配置,则可以决定要使用@Configuration
类为测试配置特定的Spring托管组件,反之亦然。
此外,某些第三方框架(例如Spring Boot)提供了一流的支持,可以同时从不同类型的资源(例如XML配置文件、Groovy脚本和@Configuration
类)中加载ApplicationContext
。过去,Spring框架不支持此标准部署。因此,Spring框架在spring-test
模块中提供的大多数SmartContextLoader
实现对于每个测试上下文仅支持一种资源类型。但是,这并不意味着你不能同时使用两者。通用规则的一个例外是GenericGroovyXmlContextLoader
和GenericGroovyXmlWebContextLoader
同时支持XML配置文件和Groovy脚本。此外,第三方框架可以选择通过@ContextConfiguration
支持位置和类的声明,并且,借助TestContext
框架中的标准测试支持,你可以选择以下选项。
如果要使用资源位置(例如XML或Groovy)和@Configuration
类的配置测试,则必须选择一个作为入口点,并且其中一个必须包含或导入另一个。例如,在XML或Groovy脚本中,可以通过使用组件扫描或将它们定义为普通的Spring bean来包括@Configuration
类,而在@Configuration
类中,可以使用@ImportResource
导入XML配置文件或Groovy脚本。请注意,此行为在语义上等同于你在生产环境中配置应用程序的方式:在生产配置中,你定义了一组XML或Groovy资源位置或一组@Configuration
类,从中加载了生产ApplicationContext
,但是你仍然包含或导入其他类型的配置的自由。
通过上下文初始化器配置上下文
若要使用上下文初始化程序为你的测试配置ApplicationContext
,请使用@ContextConfiguration
注解测试类,并使用包含对实现ApplicationContextInitializer
的类的引用的数组配置初始化程序属性。然后,使用声明的上下文初始值设定项来初始化为测试加载的ConfigurableApplicationContext
。请注意,每个声明的初始化程序支持的具体ConfigurableApplicationContext
类型必须与使用中的SmartContextLoader
创建的ApplicationContext
类型(通常是GenericApplicationContext
)兼容。此外,初始化程序的调用顺序取决于它们是实现Spring的Ordered
接口还是以Spring的@Order
注解或标准的@Priority
注解进行注释。下面的示例演示如何使用初始化程序:
使用配置类和初始化程序指定配置。
你还可以完全省略@ContextConfiguration
中的XML配置文件、Groovy脚本或组件类的声明,而仅声明ApplicationContextInitializer
类,然后这些类负责在上下文中注册Bean(例如,通过编程方式从XML文件加载Bean定义)或配置类。以下示例显示了如何执行此操作:
仅使用初始化程序来指定配置。
参考代码:
org.liyong.test.annotation.test.spring.ContextInitializerTests
上下文配置继承
@ContextConfiguration
支持boolean
inheritLocations
和inheritinitialalizer
属性,它们表示是否应该继承由超类声明的资源位置或组件类和上下文初始化器。这两个标志的默认值为true
。这意味着测试类将继承资源位置或组件类以及任何超类申明的上下文初始化器。具体来说,将测试类的资源位置或组件类附加到由超类申明的资源位置或带注解的类的列表中。同样,将给定测试类的初始化程序添加到由测试超类定义的初始化程序集。因此,子类可以选择扩展资源位置、组件类或上下文初始化程序。
如果@ContextConfiguration
中的inheritLocations
或inheritInitializers
属性被设置为false
,则测试类的资源位置或组件类和上下文初始化器将分别有效地替代超类定义的配置。
在下一个使用XML资源位置的示例中,从Base-config.xml
和Extended-config.xml依
次加载ExtendedContext
的ApplicationContext
。因此,extended-config.xml
中定义的Bean可以覆盖(即替换)base-config.xml
中定义的那些。以下示例显示了一个类如何扩展另一个类并使用其自己的配置文件和超类的配置文件:
在超类中定义的配置文件
子类中定义的配置文件。
同样,在下一个使用组件类的示例中,从BaseConfig
和ExtendedConfig
类按该顺序加载ExtendedTest
的ApplicationContext
。因此,在ExtendedConfig
中定义的Bean可以覆盖(即替换)在BaseConfig
中定义的Bean。下面的示例显示一个类如何扩展另一个类,并同时使用自己的配置类和超类的配置类:
在超类中定义的配置类
在子类中定义的配置类。
在使用上下文初始化程序的下一个示例中,通过使用BaseInitializer
和ExtendedInitializer
初始化ExtendedTest
的ApplicationContext
。但是请注意,初始化程序的调用顺序取决于它们是实现Spring的Ordered
接口还是以Spring的@Order
注解或标准的@Priority
注解进行注释。以下示例显示了一个类如何扩展另一个类并使用其自己的初始化程序和超类的初始化程序:
超类中定义的初始化器。
子类中定义的初始化程序。
使用环境配置文件进行上下文配置
Spring框架对环境和配置文件(又名“bean定义配置文件”)的概念提供了一流的支持,可以配置集成测试来激活针对各种测试场景的特定bean定义配置文件。这可以通过使用@ActiveProfiles
注解测试类并提供在加载测试的ApplicationContext
时应激活的配置文件列表来实现。
你可以将
@ActiveProfiles
与SmartContextLoader
SPI的任何实现一起使用,但较早的ContextLoader
SPI的实现不支持@ActiveProfiles
。
考虑两个带有XML配置和@Configuration
类的示例:
运行TransferServiceTest
时,会从类路径根目录中的app-config.xml
配置文件中加载其ApplicationContext
。如果检查app-config.xml
,可以看到accountRepository bean对dataSource
bean有依赖性。但是,dataSource
未被定义为顶级bean。相反,dataSource
定义了三次:在生产配置文件中、在开发配置文件中以及在默认配置文件中。
通过使用@ActiveProfiles(“dev”)
注解TransferServiceTest
,我们指示Spring TestContext
框架加载具有设置为{“dev”}
的激活配置文件的ApplicationContext
。结果,创建了一个嵌入式数据库,并用测试数据填充了数据库,并用对开发DataSource
的引用来连接accountRepository
bean。这可能是我们在集成测试中想要的。
有时将bean分配给默认配置文件很有用。只有在没有特别激活其他配置文件时,才会包含缺省配置文件中的bean。你可以使用它来定义在应用程序的默认状态中使用的后备bean。例如,你可以显式提供dev
和production
的数据源,但是当两者都不处于活动状态时,将内存中数据源定义为默认值。
以下代码清单演示了如何使用@Configuration
类而不是XML实现相同的配置和集成测试:
在此变体中,我们将XML配置分为四个独立的@Configuration
类:
ransferServiceConfig
: 通过使用@Autowired
进行依赖项注入来获取数据源。StandaloneDataConfig
: 为适合开发人员测试的嵌入式数据库定义数据源。JndiDataConfig
: 定义在生产环境中从JNDI检索的数据源。DefaultDataConfig
: 如果没有配置文件处于激活状态,则为默认的嵌入式数据库定义一个数据源。
与基于XML的配置示例一样,我们仍然使用@ActiveProfiles("dev")
注解TransferServiceTest
,但是这次我们使用@ContextConfiguration
注解指定所有四个配置类。测试类的主体本身保持完全不变。
在一个给定项目中,跨多个测试类使用一组配置文件是很常见的。因此,为避免@ActiveProfiles
注解的重复声明,可以在基类中声明一次@ActiveProfiles
,子类会自动从基类继承@ActiveProfiles
配置。在以下示例中,@ActiveProfiles
的声明(以及其他注解)已移至抽象超类AbstractIntegrationTest
:
@ActiveProfiles
还支持可用于禁用激活配置文件的继承的InheritedProfiles
属性,如以下示例所示:
此外,有时有必要以编程方式而不是声明方式来解析测试的激活配置文件,例如,基于:
当前的操作系统。
是否在持续集成构建服务器上执行测试。
存在某些环境变量。
自定义类级别注释的存在。
其他问题。
要以编程方式解析活动bean定义配置文件,可以实现自定义ActiveProfilesResolver
并使用@ActiveProfiles
的resolver
属性对其进行注册。有关更多信息,请参见相应的javadoc。下面的示例演示如何实现和注册自定义的OperatingSystemActiveProfilesResolver
:
通过测试属性源配置上下文
Spring框架对具有属性源层次结构的环境概念提供了一流的支持,你可以使用特定于测试的属性源配置集成测试。与@Configuration
类上使用的@PropertySource
注解相反,可以在测试类上声明@TestPropertySource
注解,以声明测试属性文件或内联属性的资源位置。这些测试属性源被添加到环境中为带注解的集成测试加载的ApplicationContext
的PropertySources
集合中。
你可以将
@TestPropertySource
与SmartContextLoader
SPI的任何实现一起使用,但是较早的ContextLoader
SPI的实现不支持@TestPropertySource
。
>
SmartContextLoader
的实现可通过MergedContextConfiguration
中的getPropertySourceLocations()
和getPropertySourceProperties()
方法访问合并的测试属性源值。
声明测试属性源
你可以使用@TestPropertySource的location
或value
属性来配置测试属性文件。
支持传统属性文件格式和基于XML的属性文件格式,例如: classpath:/com/example/test.properties
或file:///path/to/file.xml
。
每个路径都被解析为Spring资源。普通路径(例如 test.properties
)被视为相对于定义测试类的程序包的类路径资源。以斜杠开头的路径被视为绝对类路径资源(例如:/org/example/test.xml
)。通过使用指定的资源协议加载引用URL的路径(例如,以classpath:
、file:
或http:
为前缀的路径)。不允许使用资源位置通配符(例如* /.properties
)每个位置都必须精确评估为一个.properties
或.xml
资源。
以下示例使用测试属性文件:
指定具有绝对路径的属性文件。
你可以使用@TestPropertySource
的properties
属性,以键/值对的形式配置内联属性,如下例所示。所有键值对都作为优先级最高的单个测试PropertySource
添加到封闭环境中。
键值对支持的语法与为Java属性文件中的条目定义的语法相同:
key=value
key:value
key value
下面的示例设置两个内联属性:
通过使用键值语法的两种变体来设置两个属性。
从Spring框架5.2开始,
@TestPropertySource
可以用作可重复注解。这意味着你可以在单个测试类上具有@TestPropertySource
的多个声明,其后的@TestPropertySource
注解中的locations
和properties
将覆盖先前的@TestPropertySource
注解中的locations
和properties
。
>
此外,你可以在一个测试类上声明多个组合注解,每个注解都用
@TestPropertySource
进行元注解,所有这些@TestPropertySource
声明都将贡献给你的测试属性源。直接呈现的@TestPropertySource注解
总是优先于元呈现的@TestPropertySource
注解。换句话说,直接存在的@TestPropertySource
注解中的locations
和properties
将覆盖@TestPropertySource
注解中用作元注解的locations
和properties
。
默认属性文件检测
如果@TestPropertySource
被声明为空注解(即,没有locations
或properties
的显式值),则尝试检测相对于声明该注解的类的默认属性文件。例如,如果带注解的测试类是com.example.MyTest
,则相应的对应属性文件是classpath:com/example/MyTest.properties
。如果无法检测到默认值,则抛出IllegalStateException
。
优先顺序
测试属性的优先级高于在操作系统环境、Java系统属性或应用程序通过使用@PropertySource
声明性地或以编程方式添加的属性源中定义的属性。因此,测试属性可用于有选择地覆盖从系统和应用程序属性源加载的属性。此外,内联属性优先于从资源位置加载的属性。但是请注意,通过@DynamicPropertySource
注册的属性比通过@TestPropertySource
加载的属性具有更高的优先级。
在下一个示例中,timezone
和port
属性以及在/test.properties
中定义的任何属性都将覆盖在系统和应用程序属性源中定义的同名属性。此外,如果/test.properties
文件定义了timezone
和port
属性的条目,则这些条目将被使用properties
属性声明的内联属性所覆盖。
继承和覆盖测试属性源
@TestPropertySource
支持布尔型的inheritLocations
和inheritProperties
属性,它们表示属性文件的资源位置和超类声明的内联属性是否应该被继承。这两个标志的默认值为true
。这意味着测试类将继承任何超类声明的位置和内联属性。具体来说,测试类的位置和内联属性附加到父类声明的位置和内联属性。因此,子类可以选择扩展位置和内联属性。注意,后面出现的属性会隐藏(即覆盖)前面出现的同名属性。此外,前面提到的优先规则也适用于继承的测试属性源。
如果@TestPropertySource
中的InheritLocations
或InheritProperties
属性设置为false
,则分别为测试类设置位置或内联属性,并有效替换超类定义的配置。
在下一个示例中,BaseTest
的ApplicationContext
是通过只使用base
加载的。属性文件作为测试属性源。相反,ExtendedTest
的ApplicationContext
是通过使用base
加载的属性和扩展。属性文件作为测试属性源位置。下面的示例演示如何使用属性文件在子类及其超类中定义属性:
```java
@TestPropertySource("base.properties")
@ContextConfiguration
class BaseTest {
// ...
}
@TestPropertySource("extended.properties")
@ContextConfiguration
class ExtendedTest extends BaseTest {
// ...
}
```
在下一个示例中,仅使用内联的key1
属性来加载BaseTest
的ApplicationContext
。相反,使用内联的key1
和key2
属性来加载ExtendedTest
的ApplicationContext
。下面的示例演示如何通过使用内联属性在子类及其父类中定义属性:
通过动态属性源配置上下文
从Spring框架5.2.5开始,TestContext
框架通过@DynamicPropertySource
注解提供对动态属性的支持。此注解可用于需要向为集成测试加载的ApplicationContext
的环境中的PropertySources
集添加带有动态值的属性的集成测试。
@DynamicPropertySource
注解及其支持的基础结构最初旨在使基于Testcontainers
的测试中的属性易于暴露于Spring集成测试。但是,此功能还可以用于其生命周期在测试的ApplicationContext
之外维护的任何形式的外部资源。
与在类级别应用@TestPropertySource
注解相反,@DynamicPropertySource
必须应用于接受单个DynamicPropertyRegistry
参数的静态方法,该参数用于向环境添加名称/值
对。值是动态的,并通过Supplier
提供,只有在解析属性时才调用Supplier
。通常,方法引用被用来提供值,如下面的例子所示,它使用Testcontainers
项目在Spring ApplicationContext
之外管理一个Redis容器。通过redis.host
和redis.port
属性,测试的ApplicationContext
中的组件可以使用托管Redis容器的IP地址和端口。这些属性可以通过Spring的环境抽象访问,或者直接注入到Spring管理的组件中,例如分别通过@Value("${redis.host}")
和@Value("${redis.port}")
。
优先顺序
动态属性的优先级高于@TestPropertySource
、操作系统的环境、Java系统属性或应用程序通过@PropertySource
声明性地或以编程方式添加的属性源中加载的属性。因此,动态属性可用于有选择地覆盖通过@TestPropertySource
、系统属性源和应用程序属性源加载的属性。
**加载WebApplicationContext
**
若要指示TestContext
框架加载WebApplicationContext
而不是标准ApplicationContext
,可以使用@WebAppConfiguration
注解各自的测试类。
测试类上@WebAppConfiguration
的存在指示TestContext
框架(TCF)应该为集成测试加载WebApplicationContext
(WAC)。TCF在后台确保创建了MockServletContext
并将其提供给测试的WAC。默认情况下,你的MockServletContext
的基本资源路径设置为src/main/webapp
。这被解释为相对于JVM根目录的路径(通常是项目的路径)。如果你熟悉Maven项目中Web应用程序的目录结构,则知道src/main/webapp
是WAR根目录的默认位置。如果需要覆盖此默认值,则可以提供@WebAppConfiguration
注解的替换路径(例如,@WebAppConfiguration(“src/test/webapp”))
。如果你希望从类路径而不是文件系统中引用基本资源路径,则可以使用Spring的classpath:
前缀。
请注意,Spring对WebApplicationContext
实现的测试支持与其对标准ApplicationContext
实现的支持相当。使用WebApplicationContext
进行测试时,可以使用@ContextConfiguration
声明XML配置文件、Groovy脚本或@Configuration
类。你还可以自由地使用任何其他测试注解,如@ActiveProfiles
、@Testexecutionlistener
、@Sql
、@Rollback
和其他。
本节的其余示例展示了加载WebApplicationContext
的一些不同配置选项。以下示例显示了TestContext
框架对配置约定的支持:
如果使用@WebAppConfiguration
注解测试类而未指定资源基本路径,则资源路径实际上默认为file:src/main/webapp
。同样,如果在声明@ContextConfiguration
时未指定资源位置、组件类或上下文初始化程序,则Spring会尝试使用约定(也就是说,WacTests-context.xml
与WacTests
类或静态嵌套@Configuration
类位于同一包中)。
以下示例显示如何使用@WebAppConfiguration
显式声明资源基本路径和使用@ContextConfiguration
显式声明XML资源位置:
这里要注意的重要一点是具有这两个注解的路径的语义不同。默认情况下,@ WebAppConfiguration
资源路径基于文件系统,而@ContextConfiguration
资源位置基于类路径。下面的示例显示,我们可以通过指定Spring资源前缀来覆盖两个注解的默认资源语义:
将本示例中的注解与上一个示例进行对比。
使用Web Mock工作
为了提供全面的Web测试支持,TestContext
框架具有默认启用的ServletTestExecutionListener
。在针对WebApplicationContext
进行测试时,此TestExecutionListener
会在每个测试方法之前使用Spring Web的RequestContextHolder
来设置默认的线程本地状态,并根据通过@WebAppConfiguration
配置的基本资源路径创建MockHttpServletRequest
、MockHttpServletResponse
和ServletWebRequest
。
ServletTestExecutionListener
还确保可以将MockHttpServletResponse
和ServletWebRequest
注入到测试实例中,并且一旦测试完成,它将清除线程本地状态。
一旦为测试加载了WebApplicationContext
,你可能会发现你需要与Web模拟进行交互,例如,在调用Web组件之后设置测试fixture
或执行断言。以下示例显示可以将哪些模拟自动装配到你的测试实例。请注意,WebApplicationContext
和MockServletContext
都缓存在测试套件中,而其他模拟则由ServletTestExecutionListener
针对每个测试方法进行管理。
上下文缓存
一旦TestContext
框架为测试加载了ApplicationContext
(或WebApplicationContext
),该上下文将被缓存并重新用于在同一测试套件中声明相同唯一上下文配置的所有后续测试。要了解缓存的工作原理,重要的是要了解unique
和测试套件
的含义。
可以通过用于加载它的配置参数的组合来唯一标识ApplicationContext
。因此,使用配置参数的唯一组合来生成一个键,在该键下缓存上下文。TestContext
框架使用以下配置参数来构建上下文缓存键:
locations
(来自@ContextConfiguration
)classes
(来自@ContextConfiguration
)contextInitializerClasses
(来自@ContextConfiguration
)contextCustomizers
(来自ContextCustomizerFactory
)其中包括@DynamicPropertySource
方法,以及Spring Boot测试支持中的各种功能,例如@MockBean
和@SpyBean
。contextLoader
(来自@ContextConfiguration
)parent
(来自@ContextHierarchy
)activeProfiles
(来自@ActiveProfiles
)propertySourceLocations
(来自@TestPropertySource
)propertySourceProperties
(来自@TestPropertySource
)resourceBasePath
(来自@WebAppConfiguration
)
例如,如果TestClassA
为@ContextConfiguration
的location
(或value
)属性指定{“app-config.xml”,“test-config.xml”}
,则TestContext
框架将加载相应的ApplicationContext
并将其存储在静态上下文缓存中仅基于那些位置的key下。因此,如果TestClassB
还为其位置(通过继承显式或隐式)定义了{“app-config.xml”,“test-config.xml”}
,但未定义@WebAppConfiguration
、不同的ContextLoader
、不同的激活配置文件、不同的上下文初始化程序、不同的测试属性源或不同的父上下文,则两个测试类将共享相同的ApplicationContext
。这意味着(每个测试套件)仅需加载一次加载应用程序上下文的设置成本,并且随后的测试执行要快得多。
测试套件和分支流程
>
Spring
TestContext
框架将应用程序上下文存储在静态缓存中。这意味着上下文实际上是存储在静态变量中的。换句话说,如果测试是在单独的进程中执行的,则在每个测试执行之间都会清除静态缓存,从而有效地禁用了缓存机制。
>
为了从缓存机制中受益,所有测试必须在同一进程或测试套件中运行。这可以通过在IDE中以组的形式执行所有测试来实现。同样,在使用诸如Ant、Maven或Gradle之类的构建框架执行测试时,确保该构建框架不会在测试之间进行派生(fork多个进程)很重要。例如,如果将Maven Surefire插件的forkMode设置为always或pertest,则
TestContext
框架将无法在测试类之间缓存应用程序上下文,因此,构建过程的运行速度将大大降低。
上下文缓存的大小以默认的最大32为界。只要达到最大大小,就会使用最近最少使用(LRU)驱逐策略来驱逐和关闭旧的上下文。你可以通过设置名为spring.test.context.cache.maxSize
的JVM系统属性,从命令行或构建脚本中配置最大大小。或者,你可以使用SpringProperties
API以编程方式设置相同的属性。
由于在给定的测试套件中加载大量的应用程序上下文会导致该套件花费不必要的长时间来执行,因此准确地知道已加载和缓存了多少个上下文通常是有益的。要查看基础上下文缓存的统计信息,可以将org.springframework.test.context.cache
日志记录类别的日志级别设置为DEBUG
。
在不太可能的情况下,测试破坏了应用程序上下文并需要重新加载(例如,通过修改bean定义或应用程序对象的状态),你可以使用@DirtiesContext
注解测试类或测试方法(请参阅@DirtiesContext
中对@DirtiesContext的讨论)。这指示Spring在运行需要相同应用程序上下文的下一个测试之前,从缓存中删除上下文并重建应用程序上下文。请注意,默认情况下启用的DirtiesContextBeforeModesTestExecutionListener
和DirtiesContextTestExecutionListener
提供了对@DirtiesContext
注解的支持。
上下文层级
在编写依赖于已加载的Spring ApplicationContext
的集成测试时,通常足以针对单个上下文进行测试。但是,有时需要对ApplicationContext
实例的层次结构进行测试是有益的,甚至是必要的。例如,如果你正在开发Spring MVC Web应用程序,则通常由Spring的ContextLoaderListener
加载根WebApplicationContext
,由Spring的DispatcherServlet
加载子WebApplicationContext
。这将导致父子上下文层次结构,其中共享组件和基础设施配置在根上下文中声明,并由特定于web的组件在子上下文中使用。在Spring Batch应用程序中可以找到另一个用例,在该应用程序中,你通常具有一个父上下文,该上下文为共享批处理基础结构提供配置,而子上下文则为特定批处理作业的配置提供配置。
你可以通过在单个测试类上或在测试类层次结构中使用@ContextHierarchy
注解声明上下文配置来编写使用上下文层次结构的集成测试。如果在测试类层次结构中的多个类上声明了上下文层次结构,则还可以合并或覆盖上下文层次结构中特定命名级别的上下文配置。合并层次结构中给定级别的配置时,配置资源类型(即XML配置文件或组件类)必须一致。否则,在使用不同资源类型配置的上下文层次结构中具有不同级别是完全可以接受的。
本节中其余的基于JUnit Jupiter的示例显示了需要使用上下文层次结构的集成测试的常见配置方案。
具有上下文层次结构的单个测试类
ControllerIntegrationTests
通过声明一个上下文层次结构来代表Spring MVC Web应用程序的典型集成测试场景,该上下文层次结构包含两个级别,一个层次用于根WebApplicationContext
(通过使用TestAppConfig
@Configuration类加载),一个层次用于调度程序Servlet WebApplicationContext
(通过使用WebConfig
@Configuration
类加载)。自动装配到测试实例的WebApplicationContext
是用于子上下文(即,层次结构中的最低上下文)的WebApplicationContext
。
以下清单显示了此配置方案:
参考代码:
org.liyong.test.annotation.test.spring.ControllerIntegrationTests
具有隐式父上下文的类层次结构
本示例中的测试类在测试类层次结构中定义了上下文层次结构。AbstractWebTests
在Spring驱动的Web应用程序中声明根WebApplicationContext
的配置。但是请注意,AbstractWebTests
不会声明@ContextHierarchy
。因此,AbstractWebTests
的子类可以选择参与上下文层次结构或遵循@ContextConfiguration
的标准语义。SoapWebServiceTests
和RestWebServiceTests
都扩展了AbstractWebTests
并使用@ContextHierarchy
定义了上下文层次结构。结果是,加载了三个应用程序上下文(每个@ContextConfiguration
声明一个),并且基于AbstractWebTests
中的配置加载的应用程序上下文被设置为具体子类加载的每个上下文的父上下文。
参考代码:
org.liyong.test.annotation.test.spring.RestWebServiceTests
合并上下文层次结构配置的类层次结构
此示例中的类显示了使用命名层次结构级别的目的,以及合并上下文层次结构中特定级别的配置。BaseTests
在层次结构中定义了两个级别,parent
和child
。ExtendedTests
扩展BaseTests
并指示Spring TestContext
框架合并子层次结构级别的上下文配置,方法是<u>确保在@ContextConfiguration
的name属性中声明的名称均为子元素</u>。结果是加载了三个应用程序上下文:一个用于/app-config.xml
、一个用于/user-config.xml
、一个用于{/user-config.xml
,/order-config.xml}
。与前面的示例一样,将从/app-config.xml
加载的应用程序上下文设置为从/user-config.xml
和{“/user-config.xml","/order-config.xml“}
加载的上下文的父上下文(合并配置文件)。以下清单显示了此配置方案:
参考代码:
org.liyong.test.annotation.test.spring.ExtendedTests
具有覆盖的上下文层次结构配置的类层次结构
与前面的示例相反,此示例演示了如何通过将@ContextConfiguration
中的InheritLocations
标志设置为false
来覆盖上下文层次结构中给定命名级别的配置。因此,ExtendedTests
的应用程序上下文仅从/test-user-config.xml
加载,并且其父级设置为从/app-config.xml
加载的上下文。以下清单显示了此配置方案:
清除上下文层次结构中的上下文
>
如果你在一个测试中使用@DirtiesContext,该测试的上下文被配置为上下文层次结构的一部分,那么你可以使用hierarchyMode标志来控制如何清除上下文缓存。有关更多详细信息,请参见Spring Testing Annotations中的@DirtiesContext和[@DirtiesContext](https://docs.spring.io/spring-framework/docs/5.2.7.RELEASE/javadoc-api/org/springframework/test/annotation/DirtiesContext.html) javadoc的讨论。
参考代码:
org.liyong.test.annotation.test.spring.ExtendedTests1
###### 3.5.6 测试装置的依赖注入
当使用DependencyInjectionTestExecutionListener
(默认配置)时,测试实例的依赖项是从使用@ContextConfiguration
或相关注解配置应用程序上下文中的bean注入的。你可以使用setter
注入、字段注入、或同时使用这两种方法,具体取决于你选择的注解以及是否将它们放在setter
方法或字段上。如果你使用的是JUnit Jupiter,则还可以选择使用构造函数注入(请参阅带有SpringExtension的依赖注入)。为了与Spring基于注解的注入支持保持一致,你还可以将Spring的@Autowired
注解或JSR-330中的@Inject
注解用于字段注入和setter 注入。
对于JUnit Jupiter以外的测试框架,
TestContext
框架不参与测试类的实例化。因此,将@Autowired
或@Inject
用于构造函数对测试类无效。
尽管在生产代码中不鼓励使用字段注入,但是在测试代码中字段注入实际上是很自然的。理由是你永远不会直接实例化测试类。因此,不需要在测试类上调用公共构造函数或
setter
方法。
因为@Autowired
用于按类型执行自动装配,所以如果你具有多个相同类型的Bean定义,那么对于那些特定的Bean,你将不能依靠这种方法。在这种情况下,可以将@Autowired
与@Qualifier
结合使用。你也可以选择将@Inject
与@Named
结合使用。或者,如果你的测试类可以访问其ApplicationContext
,则可以通过使用(例如)对applicationContext.getBean(“ titleRepository“,TitleRepository.class)
的调用来执行显式查找。
如果你不希望将依赖项注入应用于测试实例,请不要使用@Autowired
或@Inject
注解字段或设置器方法。或者,你可以通过显式地用@TestExecutionListeners
配置你的类,并从监听器列表中忽略DependencyInjectionTestExecutionListener.class
来禁用依赖注入。
考虑测试HibernateTitleRepository
类的场景,如目标部分所述。接下来的两个代码清单演示了@Autowired
在字段和setter
方法上的用法。在所有示例代码清单之后显示了应用程序上下文配置。
以下代码清单中的依赖项注入行为并非特定于JUnit Jupiter。相同的
DI
技术可以与任何受支持的测试框架结合使用。
>
以下示例对静态断言方法(例如
assertNotNull()
)进行了调用,但没有在声明前添加Assertions
。在这种情况下,假定该方法是通过示例中未显示的import static
声明正确导入的。
第一个代码清单显示了使用@Autowired
进行字段注入的测试类的基于JUnit Jupiter的实现:
或者,你可以将类配置为使用@Autowired
进行setter
注入,如下所示:
前面的代码清单使用@ContextConfiguration
注解引用的相同XML上下文文件(即,repository-config.xml
)。下面显示了此配置:
如果你是从Spring提供的测试基类扩展而来的,而该基类恰巧在其
setter
方法之一上使用@Autowired
,则可能在应用程序上下文中定义了多个受影响类型的Bean(例如,多个DataSource
Bean)。在这种情况下,你可以覆盖setter方法,并使用@Qualifier
注解指示特定的目标bean,如下所示(但请确保也委托给超类中的重写方法):
>
```java
// ...
@Autowired
@Override
public void setDataSource(@Qualifier("myDataSource") DataSource dataSource) {
super.setDataSource(dataSource);
}
// ...
```
>
指定的限定符值指示要注入的特定
DataSource
Bean,从而将类型匹配的范围缩小到特定Bean。其值与相应的<bean>定义中的<qualifier>声明匹配。Bean名称用作后备限定符值,因此你也可以在该名称中有效地指向特定的Bean(如先前所示,假设myDataSource
是BeanID
)。
作者
个人从事金融行业,就职过易极付、思建科技、某网约车平台等重庆一流技术团队,目前就职于某银行负责统一支付系统建设。自身对金融行业有强烈的爱好。同时也实践大数据、数据存储、自动化集成和部署、分布式微服务、响应式编程、人工智能等领域。同时也热衷于技术分享创立公众号和博客站点对知识体系进行分享。关注公众号:青年IT男 获取最新技术文章推送!
博客地址: http://youngitman.tech
CSDN: https://blog.csdn.net/liyong1028826685
微信公众号:
技术交流群:
版权声明: 本文为 InfoQ 作者【青年IT男】的原创文章。
原文链接:【http://xie.infoq.cn/article/8ebe4998a29a1a9b53d739001】。
本文遵守【CC BY-NC】协议,转载请保留原文出处及本版权声明。
评论