Spring TestContext
框架(位于org.springframework.test.context
包中)提供了通用的、注解驱动的单元和集成测试支持,这些支持与所使用的测试框架无关。TestContext
框架还非常重视约定优于配置,你可以通过基于注解的配置覆盖合理的默认值。
除了通用测试基础结构之外,TestContext
框架还为JUnit 4,JUnit Jupiter(AKA JUnit 5)和TestNG提供了显式支持。对于JUnit 4和TestNG,Spring提供了抽象支持类。此外,Spring为JUnit 4提供了自定义JUnit Runner和自定义JUnit规则,以及JUnit Jupiter的自定义扩展,可让你编写所谓的POJO测试类。不需要POJO测试类来扩展特定的类层次结构,例如抽象支持类。下一节概述了TestContext
框架的内部。如果你仅对使用框架感兴趣,而对使用自己的自定义监听器或自定义加载程序进行扩展不感兴趣,请直接转到配置(上下文管理 、依赖项注入、事务管理、支持类和注解支持部分。
3.5.1 关键抽象
该框架的核心由TestContextManager
类和TestContext
,TestExecutionListener
和SmartContextLoader
接口组成。为每个测试类创建一个TestContextManager
(例如,用于在JUnit Jupiter中的单个测试类中执行所有测试方法)。反过来,TestContextManager
管理包含当前测试上下文的TestContext
。随着测试的进行,TestContextManager
还更新了TestContext
的状态,并委托给TestExecutionListener
实现,该实现通过提供依赖项注入,管理事务等来检测实际的测试执行。SmartContextLoader
负责为给定的测试类加载ApplicationContext
。有关更多信息和各种实现的示例,请参见javadoc和Spring测试套件。
TestContext
TestContext
封装了在其中执行测试的上下文(与使用中的实际测试框架无关),并为其负责的测试实例提供了上下文管理和缓存支持。如果需要,TestContext
还委托给SmartContextLoader
来加载ApplicationContext
。
TestContextManager
TestContextManager
是Spring TestContext
框架的主要入口点,并负责管理单个TestContext
并在定义良好的测试执行点向每个注册的TestExecutionListener
发出事件信号:
- 在任何
before
类之前或在特定测试框架的所有方法之前。 - 测试实例后处理。
- 在任何
before
或在每个特定测试框架的方法之前。 - 在执行测试方法之前但在测试设置之后。
- 在测试方法执行之后,但在测试拆卸之前。
- 之后的任何方法或之后的每一个特定的测试框架。
- 在特定测试框架的任何类后或所有方法之后。
TestExecutionListener
TestExecutionListener
定义用于对由注册监听器的TestContextManager
发布的测试执行事件做出反应的API。请参阅TestExecutionListener配置。
上下文加载器
ContextLoader
是一个策略接口,用于为Spring TestContext
框架管理的集成测试加载ApplicationContext
。你应该实现SmartContextLoader
而不是此接口,以提供对组件类,激活的bean定义配置文件、测试属性源、上下文层次结构和WebApplicationContext
支持的支持。
SmartContextLoader
是ContextLoader
接口的扩展,它取代了原始的最小ContextLoader
SPI。具体来说,SmartContextLoader
可以选择处理资源位置、组件类或上下文初始化器。此外,SmartContextLoader
可以在其加载的上下文中设置激活Bean定义配置文件并测试属性源。
Spring提供了以下实现:
DelegatingSmartContextLoader
: 它是两个默认加载器之一,它在内部委派给AnnotationConfigContextLoader
、GenericXmlContextLoader
或GenericGroovyXmlContextLoader
,具体取决于为测试类声明的配置或默认位置或默认配置类的存在。仅当Groovy在类路径上时才启用Groovy支持。WebDelegatingSmartContextLoader
: 它是两个默认加载器之一,它在内部委派给AnnotationConfigWebContextLoader
、GenericXmlWebContextLoader或GenericGroovyXmlWebContextLoader
,具体取决于为测试类声明的配置或默认位置或默认配置类的存在。仅当测试类上存在@WebAppConfiguration
时,才使用WebContextLoader
。仅当Groovy在类路径上时才启用Groovy支持。AnnotationConfigContextLoader
:从组件类加载标准ApplicationContext
。AnnotationConfigWebContextLoader
: 从组件类加载WebApplicationContext
。GenericGroovyXmlContextLoader
: 从Groovy脚本或XML配置文件的资源位置加载标准ApplicationContext
。GenericGroovyXmlWebContextLoader
: 从Groovy脚本或XML配置文件的资源位置加载WebApplicationContext
。GenericXmlContextLoader
: 从XML资源位置加载标准ApplicationContext
。GenericXmlWebContextLoader
: 从XML资源位置加载WebApplicationContext
。GenericPropertiesContextLoader
:从Java属性文件加载标准ApplicationContext
。
3.5.2 引导TestContext框架
Spring TestContext
框架内部的默认配置足以满足所有常见用例。但是,有时开发团队或第三方框架希望更改默认的ContextLoader
,实现自定义的TestContext
或ContextCache
,扩展默认的ContextCustomizerFactory
和TestExecutionListener
实现等等。为了对TestContext
框架的运行方式进行低级别控制,Spring提供了引导策略。
TestContextBootstrapper
定义了用于引导TestContext
框架的SPI。TestContextManager
使用TestContextBootstrapper
加载当前测试的TestExecutionListener
实现并构建它管理的TestContext
。你可以直接使用@BootstrapWith
或作为元注解,为测试类(或测试类层次结构)配置自定义引导策略。如果没有通过使用@BootstrapWith
显式配置引导程序,则根据@WebAppConfiguration
的存在,使用DefaultTestContextBootstrapper
或WebTestContextBootstrapper
。
由于TestContextBootstrapper
SPI将来可能会更改(以适应新的需求),我们强烈建议实现者不要直接实现此接口,而应扩展AbstractTestContextBootstrapper
或其具体子类之一。
3.5.3 TestExecutionListener
配置
Spring提供了以下TestExecutionListener
实现,这些实现默认情况下按以下顺序注册:
ServletTestExecutionListener
:为WebApplicationContext
配置Servlet API模拟。DirtiesContextBeforeModesTestExecutionListener
:处理before
模式的@DirtiesContext
注解。DependencyInjectionTestExecutionListener
: 为测试实例提供依赖项注入。DirtiesContextTestExecutionListener
: 处理after
模式的@DirtiesContext
注解。TransactionalTestExecutionListener
: 提供具有默认回滚语义的事务测试执行。SqlScriptsTestExecutionListener
: 运行使用@Sql
注释配置的SQL脚本。EventPublishingTestExecutionListener
: 将测试执行事件发布到测试的ApplicationContext
中(请参阅测试执行事件)。
注册TestExecutionListener
实现
你可以使用@TestExecutionListeners
注解为测试类及其子类注解TestExecutionListener
实现。有关详细信息和示例,请参见注解支持和@TestExecutionListeners的javadoc。
默认TestExecutionListener实现自动发现
通过使用@TestExecutionListeners
注册TestExecutionListener
实现适用于有限测试方案中使用的自定义监听器。但是,如果需要在整个测试套件中使用自定义监听器,则会变得很麻烦。通过SpringFactoriesLoader
机制支持自动发现默认的TestExecutionListener
实现,可以解决这个问题。
具体来说,spring-test
模块在其META-INF/spring.factories
属性文件中的key
为org.springframework.test.context.TestExecutionListener
下声明所有核心默认TestExecutionListener
实现。第三方框架和开发人员可以通过自己的META-INF/spring.factories
属性文件以相同的方式将自己的TestExecutionListener
实现贡献到默认监听器列表中。
TestExecutionListener顺序实现
当TestContext
框架通过上述SpringFactoriesLoader
机制发现默认TestExecutionListener
实现时,实例化的监听器将使用Spring的AnnotationAwareOrderComparator
进行排序,该类将使用Spring的Ordered
接口和@Order注解进行排序。Spring提供的AbstractTestExecutionListener
和所有默认的TestExecutionListener
实现以适当的值实现Ordered
。因此,第三方框架和开发人员应通过实施Ordered
或声明@Order
来确保按默认顺序注册其默认的TestExecutionListener
实现。请参阅javadoc以获取核心默认TestExecutionListener
实现的getOrder()
方法,以获取有关为每个核心监听器分配哪些值的详细信息。
TestExecutionListener合并实现
如果通过@TestExecutionListeners
注册了自定义TestExecutionListener
,则不会注册默认监听器。在大多数常见的测试方案中,这有效地迫使开发人员手动声明除任何自定义监听器之外的所有默认监听器。
下面的清单演示了这种配置样式:
@ContextConfiguration
@TestExecutionListeners({
MyCustomTestExecutionListener.class,
ServletTestExecutionListener.class,
DirtiesContextBeforeModesTestExecutionListener.class,
DependencyInjectionTestExecutionListener.class,
DirtiesContextTestExecutionListener.class,
TransactionalTestExecutionListener.class,
SqlScriptsTestExecutionListener.class
})
class MyTest {
// class body...
}
这种方法的挑战在于,它要求开发人员确切地知道默认情况下注册了哪些监听器。此外,默认的监听器集可以随版本的不同而变化-例如,在Spring框架4.1中引入了SqlScriptsTestExecutionListener
,在Spring框架4.2中引入了DirtiesContextBeforeModesTestExecutionListener
。此外,诸如Spring Boot和Spring Security之类的第三方框架通过使用上述自动发现机制注册了自己的默认TestExecutionListener
实现。
为避免必须了解并重新声明所有默认监听器,可以将@TestExecutionListeners
的mergeMode
属性设置为MergeMode.MERGE_WITH_DEFAULTS
。MERGE_WITH_DEFAULTS
表示应将本地声明的监听器与默认监听器合并。合并算法可确保从列表中删除重复项,并确保根据AnnotationAwareOrderComparator
的语义对合并后的监听器集进行排序,如Ordering TestExecutionListener实现中所述。如果监听器实现Ordered
或使用@Order
进行注解,则它可以影响将其与默认值合并的位置。否则,合并时,本地声明的监听器将追加到默认侦听器列表中。
例如,如果上一个示例中的MyCustomTestExecutionListener
类将顺序值(例如500)配置为小于ServletTestExecutionListener
的顺序(恰好是1000),则MyCustomTestExecutionListener
可以自动与默认列表合并。在ServletTestExecutionListener
前面,并且前面的示例可以替换为以下示例:
@ContextConfiguration
@TestExecutionListeners(
listeners = MyCustomTestExecutionListener.class,
mergeMode = MERGE_WITH_DEFAULTS
)
class MyTest {
// class body...
}
3.5.4 测试执行事件
Spring框架5.2中引入的EventPublishingTestExecutionListener
提供了一种实现自定义TestExecutionListener
的替代方法。测试的ApplicationContext
中的组件可以监听EventPublishingTestExecutionListener
发布的以下事件,每个事件都与TestExecutionListener
API中的方法相对应。
BeforeTestClassEvent
PrepareTestInstanceEvent
BeforeTestMethodEvent
BeforeTestExecutionEvent
AfterTestExecutionEvent
AfterTestMethodEvent
AfterTestClassEvent
只有当
ApplicationContext
已经加载时,才会发布这些事件。
这些事件可能由于各种原因被使用,例如重置模拟bean或跟踪测试执行。使用测试执行事件而不是实现自定义TestExecutionListener
的一个优势是,测试执行事件可以由在测试ApplicationContext
中注册的任何Spring bean所使用,并且此类bean可以直接受益于依赖项注入和ApplicationContext
的其他功能。相反,TestExecutionListener
在ApplicationContext
中不是bean。
为了监听测试执行事件,Spring Bean可以选择实现org.springframework.context.ApplicationListener
接口。或者,可以使用@EventListener
注解监听器方法,并将监听方法配置为监听上面列出的特定事件类型之一(请参阅基于注解的事件监听器)。由于这种方法的流行,Spring提供了以下专用的@EventListener
注解,以简化测试执行事件监听器的注册。这些注解驻留在org.springframework.test.context.event.annotation
包中。
@BeforeTestClass
@PrepareTestInstance
@BeforeTestMethod
@BeforeTestExecution
@AfterTestExecution
@AfterTestMethod
@AfterTestClass
参考代码:
org.liyong.test.annotation.test.spring.TestExecutionEventTest
异常处理
默认情况下,如果测试执行事件监听器在使用事件时抛出异常,则该异常将传播到使用中的基础测试框架(例如JUnit或TestNG)。例如,如果使用BeforeTestMethodEvent
导致异常,则相应的测试方法将因异常而失败。相反,如果异步测试执行事件监听器引发异常,则该异常不会传播到基础测试框架。有关异步异常处理的更多详细信息,请查阅@EventListener
类级javadoc。
异步监听器
如果你希望特定的测试执行事件监听器异步处理事件,你可以使用Spring的常规@Async支持。有关更多详细信息,请查阅@EventListener
的类级javadoc。
参考代码:
org.liyong.test.annotation.test.spring.TestExecutionEventTest
作者
个人从事金融行业,就职过易极付、思建科技、某网约车平台等重庆一流技术团队,目前就职于某银行负责统一支付系统建设。自身对金融行业有强烈的爱好。同时也实践大数据、数据存储、自动化集成和部署、分布式微服务、响应式编程、人工智能等领域。同时也热衷于技术分享创立公众号和博客站点对知识体系进行分享。关注公众号:青年IT男 获取最新技术文章推送!
博客地址: http://youngitman.tech
CSDN: https://blog.csdn.net/liyong1028826685
微信公众号:
技术交流群: