Spring 对集成测试的支持和单元的最佳实践测试

版本 6.0.0

本章介绍了 Spring 对集成测试的支持和单元的最佳实践测试。Spring团队提倡测试驱动开发（TDD）。春天团队有发现正确使用反转控制（IoC）确实使两个单元和集成测试更容易（因为存在二传手方法和适当的类上的构造函数使它们更容易在测试中连接在一起，而无需设置服务定位器注册表和类似结构）。

1. 弹簧测试简介

测试是企业软件开发不可或缺的一部分。本章重点介绍 IoC 原则对单元测试的附加值及其优势 Spring 框架对集成测试的支持。（一企业中测试的彻底处理超出了本参考的范围手动。

2. 单元测试

依赖关系注入应该使代码对容器的依赖性降低采用传统的J2EE / Java EE开发。构成应用程序的 POJO 应该可以在 JUnit 或 TestNG 测试中进行测试，对象通过使用运算符实例化，没有 Spring 或任何其他容器。您可以使用模拟对象（与其他有价值的测试技术结合使用）来单独测试代码。如果您遵循 Spring 的架构建议，则生成的分层干净代码库的组件化有助于更轻松地进行单元测试。例如您可以通过存根或模拟 DAO 或存储库接口来测试服务层对象，无需在运行单元测试时访问持久性数据。new

真正的单元测试通常运行得非常快，因为没有运行时基础结构建立。强调真正的单元测试作为开发方法的一部分可以提高您的生产力。您可能不需要测试章节的这一部分来帮助您编写针对基于 IoC 的应用程序进行有效的单元测试。对于某些单元测试方案，但是，Spring 框架提供了模拟对象和测试支持类，它们在本章中进行了介绍。

2.1. 模拟对象

Spring 包含许多专门用于模拟的软件包：

环境
金迪
Servlet API
弹簧网反应式

2.1.1. 环境

该包包含 theandabstractions 的模拟实现（请参阅Bean 定义配置文件和PropertySourceAbstraction）.并且对于开发很有用对依赖于特定于环境的属性的代码进行容器外测试。org.springframework.mock.envEnvironmentPropertySourceMockEnvironmentMockPropertySource

2.1.2. JNDI

该软件包包含 JNDI 的部分实现 SPI，可用于为测试套件或独立设置简单的 JNDI 环境应用。例如，如果 JDBC 实例绑定到同一个 JNDI 测试代码中的名称与在 Jakarta EE 容器中的名称一样，您可以重用这两个应用程序代码和测试方案中的配置，无需修改。org.springframework.mock.jndiDataSource

软件包中的模拟 JNDI 支持是从 Spring Framework 5.2 开始正式弃用，转而支持第三个的完整解决方案诸如Simple-JNDI之类的政党。`org.springframework.mock.jndi`

2.1.3. servlet API

该软件包包含一套全面的 Servlet API 模拟对象，用于测试 Web 上下文、控制器和筛选器。这些模拟对象针对的是Spring的Web MVC框架的使用，通常更多比动态模拟对象（如EasyMock）更方便使用或替代的 Servlet API 模拟对象（如MockObjects）。org.springframework.mock.web

从 Spring Framework 6.0 开始，模拟对象基于 Servlet 6.0 API。org.springframework.mock.web

Spring MVC 测试框架建立在模拟 Servlet API 对象之上，以提供 Spring MVC 的集成测试框架。参见模拟Mvc。

2.1.4. 弹簧网反应式

该包包含模拟实现和用于 WebFlux 应用程序。该包包含一个模拟取决于这些模拟请求和响应对象。org.springframework.mock.http.server.reactiveServerHttpRequestServerHttpResponseorg.springframework.mock.web.serverServerWebExchange

从同一个抽象扩展两者基类作为特定于服务器的实现，并与其共享行为。为例如，模拟请求一旦创建就不可变，但您可以使用方法发件人以创建修改后的实例。MockServerHttpRequestMockServerHttpResponsemutate()ServerHttpRequest

为了使模拟响应正确实现写入协定并返回写入完成句柄（即），默认情况下，它使用 awith，它缓冲数据并使其可用于测试中的断言。应用程序可以设置自定义写入函数（例如，测试无限流）。Mono<Void>Fluxcache().then()

WebTestClient基于模拟请求和响应构建，以支持在没有 HTTP 服务器的情况下测试 WebFlux 应用程序。客户端还可用于使用正在运行的服务器进行端到端测试。

2.2. 单元测试支持类

Spring 包含许多可以帮助进行单元测试的类。他们一分为二类别：

一般测试实用程序
春季 MVC 测试实用程序

2.2.1. 一般测试实用程序

该软件包包含几个通用实用程序用于单元测试和集成测试。org.springframework.test.util

AopTestUtils是与 AOP 相关的实用程序方法。可以使用这些方法获取对隐藏在一个或多个 Spring 代理后面的底层目标对象。例如，如果您通过使用 EasyMock 或 Mockito 等库将 Bean 配置为动态模拟，并且模拟被包装在 Spring 代理中，您可能需要直接访问底层模拟以配置对其的期望并执行验证。对于春天的核心AOP 实用程序，请参阅 AopUtils 和AopProxyUtils。

ReflectionTestUtils是一个基于反射的实用工具方法的集合。您可以在测试中使用这些方法需要更改常量值、设置非字段的场景，调用非 setter 方法，或调用非配置或生命周期测试应用程序代码时用于以下用例的回调方法：publicpublicpublic

ORM框架（如JPA和Hibernate）可以容纳访问域实体中属性的 Setter（与 Setter）方法相反。privateprotectedpublic
Spring 对注释的支持（例如，和），为字段、二传手方法提供依赖注入，和配置方法。@Autowired@Inject@Resourceprivateprotected
使用注释，例如 andfor 生命周期回调方法。@PostConstruct@PreDestroy

TestSocketUtils是一个简单的用于查找可用 TCP 端口的实用程序用于集成测试场景。localhost

2.2.2. 弹簧 MVC 测试实用程序

该软件包包含ModelAndViewAssert，您可以与JUnit，TestNG或任何其他测试框架结合使用以进行单元测试处理Spring MVC对象。org.springframework.test.webModelAndView

3. 集成测试

本节（本章其余大部分内容）介绍 Spring 的集成测试应用。它包括以下主题：

概述
集成测试的目标
JDBC 测试支持
附注
Spring TestContext Framework
模拟MVC

3.1. 概述

能够在不需要的情况下执行一些集成测试非常重要部署到应用程序服务器或连接到其他企业基础结构。这样做可以测试以下内容：

Spring IoC 容器上下文的正确接线。
使用 JDBC 或 ORM 工具访问数据。这可能包括正确性等内容的 SQL 语句、休眠查询、JPA 实体映射等。

Spring 框架为模块中的集成测试提供了一流的支持。实际 JAR 文件的名称可能包含发行版本也可能是长篇，具体取决于您获得的位置它来自（有关说明，请参阅依赖项管理部分）。该库包括包，其中包含用于使用 Spring 容器进行集成测试的有价值的类。此测试不依赖于应用程序服务器或其他部署环境。此类测试是运行速度比单元测试慢，但比等效的硒测试快得多，或者依赖于部署到应用程序服务器的远程测试。spring-testorg.springframework.testorg.springframework.test

单元和集成测试支持以注释驱动的Spring TestContext Framework的形式提供。TestContext 框架是与使用的实际测试框架无关，允许测试检测在各种环境中，包括JUnit，TestNG等。

3.2. 集成测试的目标

Spring 的集成测试支持具有以下主要目标：

在测试之间管理Spring IoC 容器缓存。
提供测试夹具实例的依赖关系注入。
提供适合集成测试的事务管理。
提供特定于Spring 的基类，以帮助编写集成测试的开发人员。

接下来的几节将介绍每个目标，并提供实现和配置详细信息。

3.2.1. 上下文管理和缓存

Spring TestContext Framework 提供了 Spring 实例和实例以及缓存的一致加载。这些背景。支持加载上下文的缓存非常重要，因为启动时间可能会成为一个问题——不是因为 Spring 本身的开销，而是因为 Spring 容器实例化的对象需要时间来实例化。为例如，具有 50 到 100 个休眠映射文件的项目可能需要 10 到 20 秒才能加载映射文件，并在每次测试中运行每个测试之前产生该成本夹具会导致整体测试运行速度变慢，从而降低开发人员的工作效率。ApplicationContextWebApplicationContext

测试类通常声明 XML 或 Groovy 的资源位置数组配置元数据（通常在类路径中）或组件类数组用于配置应用程序。这些位置或类与或类似于为生产指定的 inor 其他配置文件部署。web.xml

默认情况下，加载后，配置将重用于每个测试。因此，每个测试套件仅产生一次设置成本，随后的测试执行要快得多。在这种情况下，术语“测试套件”是指在同一环境中运行的所有测试 JVM — 例如，所有测试都从给定项目的 Ant、Maven 或 Gradle 构建中运行或模块。在极少数情况下，测试会损坏应用程序上下文并需要重新加载（例如，通过修改 Bean 定义或应用程序的状态）对象）可以将测试上下文框架配置为重新加载配置和在执行下一个测试之前重新生成应用程序上下文。ApplicationContext

请参阅上下文管理和上下文缓存与测试上下文框架。

3.2.2. 测试治具的依赖注入

当 TestContext 框架加载应用程序上下文时，它可以选择使用依赖关系注入配置测试类的实例。这提供了一个使用预配置的 bean 设置测试夹具的便捷机制应用程序上下文。这里的一个重要好处是，您可以重用应用程序上下文跨各种测试场景（例如，用于配置 Spring 管理的对象）图、事务代理、实例等），从而避免了需要为单个测试用例复制复杂的测试夹具设置。DataSource

例如，考虑一个场景，其中我们有一个类（）实现域实体的数据访问逻辑。我们想写测试以下方面的集成测试：HibernateTitleRepositoryTitle

弹簧配置：基本上，与bean配置相关的一切都正确和存在吗？HibernateTitleRepository
休眠映射文件配置：所有映射是否正确，并且是是否正确设置延迟加载？
的逻辑：是否配置了此类的实例按预期执行？HibernateTitleRepository

请参阅使用TestContext 框架对测试夹具进行依赖关系注入。

3.2.3. 事务管理

在访问真实数据库的测试中，一个常见问题是它们对持久性存储。即使使用开发数据库，对状态的更改也可能会影响将来的测试。此外，许多操作（例如插入或修改持久化）数据 — 不能在事务之外执行（或验证）。

TestContext 框架解决了这个问题。默认情况下，框架创建为每个测试回滚事务。您可以编写可以假设存在的代码的交易。如果在测试中调用事务代理对象，它们的行为根据其配置的事务语义正确。此外，如果测试方法在事务中运行时删除所选表的内容为测试进行管理，默认情况下事务回滚，数据库返回到执行测试之前的状态。事务性支持由使用在测试的应用程序上下文中定义的 ABEAN。PlatformTransactionManager

如果您希望提交事务（不寻常，但偶尔在您想要特定测试来填充或修改数据库），您可以告诉 TestContext 框架，使事务提交，而不是使用 @Commit注释回滚。

请参阅TestContext 框架的事务管理。

3.2.4. 集成测试的支持类

Spring TestContext 框架提供了几个支持类，这些类简化集成测试的编写。这些基本测试类提供定义明确的挂钩到测试框架以及方便的实例变量和方法，这使您可以访问：abstract

该，用于执行显式 Bean 查找或测试状态上下文作为一个整体。ApplicationContext
A、用于执行SQL语句查询数据库。你可以使用这样的用于在执行数据库相关之前和之后确认数据库状态的查询应用程序代码，并且 Spring 确保此类查询在同一范围内运行事务作为应用程序代码。与ORM工具结合使用时，请确保以避免误报。JdbcTemplate

此外，您可能希望创建自己的自定义应用程序范围的超类特定于项目的实例变量和方法。

请参阅TestContext 框架的支持类。

3.3. JDBC 测试支持

该包包含，这是一个用于简化标准数据库的 JDBC 相关实用程序函数的集合测试方案。具体来说，提供以下静态实用程序方法。org.springframework.test.jdbcJdbcTestUtilsJdbcTestUtils

countRowsInTable(..)：计算给定表中的行数。
countRowsInTableWhere(..)：通过使用规定条款。WHERE
deleteFromTables(..)：删除指定表中的所有行。
deleteFromTableWhere(..)：使用提供的子句从给定表中删除行。WHERE
dropTables(..)：删除指定的表。

3.4. 注释

本节介绍在测试 Spring 应用程序时可以使用的注释。它包括以下主题：

弹簧测试注释
标准注释支持
春季 JUnit 4 测试注释
春季JUnit木星测试注释
元注释支持测试。

3.4.1. 弹簧测试注释

Spring 框架提供了以下一组特定于 Spring 的注释，您可以可以在单元测试和集成测试中与 TestContext 框架结合使用。请参阅相应的 javadoc 以获取更多信息，包括默认属性值、属性别名和其他详细信息。

Spring 的测试注释包括以下内容：

@BootstrapWith
@ContextConfiguration
@WebAppConfiguration
@ContextHierarchy
@ActiveProfiles
@TestPropertySource
@DynamicPropertySource
@DirtiesContext
@TestExecutionListeners
@RecordApplicationEvents
@Commit
@Rollback
@BeforeTransaction
@AfterTransaction
@Sql
@SqlConfig
@SqlMergeMode
@SqlGroup

`@BootstrapWith`

@BootstrapWith是一个类级注释，可用于配置 Spring TestContext Framework 是引导的。具体来说，您可以使用指定自定义。有关更多详细信息，请参阅有关引导TestContext框架的部分。@BootstrapWithTestContextBootstrapper

`@ContextConfiguration`

@ContextConfiguration定义用于确定如何加载和配置 ANFOR 集成测试。具体而言，声明应用程序上下文资源或组件用于加载上下文。ApplicationContext@ContextConfigurationlocationsclasses

资源位置通常是 XML 配置文件或 Groovy 脚本，位于类路径，而组件类通常是类。然而资源位置还可以引用文件系统中的文件和脚本，以及组件类可以是类，类等。有关更多详细信息，请参阅组件类。@Configuration@Component@Service

下面的示例演示引用 XML 的注释文件：@ContextConfiguration

@ContextConfiguration("/test-config.xml") 
class XmlApplicationContextTests {
    // class body...
}

以下示例显示了引用类的注释：@ContextConfiguration

@ContextConfiguration(classes = TestConfig.class) 
class ConfigClassApplicationContextTests {
    // class body...
}

作为替代方法或除了声明资源位置或组件类之外，您可以使用来声明类。以下示例显示了这种情况：@ContextConfigurationApplicationContextInitializer

@ContextConfiguration(initializers = CustomContextInitializer.class) 
class ContextInitializerTests {
    // class body...
}

您可以选择使用将策略声明为井。但请注意，您通常不需要显式配置加载程序，由于默认加载程序支持和任一资源元件。@ContextConfigurationContextLoaderinitializerslocationsclasses

以下示例同时使用位置和加载程序：

@ContextConfiguration(locations = "/test-context.xml", loader = CustomContextLoader.class) 
class CustomLoaderXmlApplicationContextTests {
    // class body...
}

有关更多详细信息，请参阅上下文管理、@Nested测试类配置和 javadocs。@ContextConfiguration

`@WebAppConfiguration`

@WebAppConfiguration是一个类级注释，可用于声明集成测试的加载应为 A。仅仅存在测试类就可以确保为测试加载 ais，使用默认值 for 到 Web 应用程序根目录的路径（即资源基本路径）。资源基路径在后台用于创建，该路径用作测试的。ApplicationContextWebApplicationContext@WebAppConfigurationWebApplicationContext"file:src/main/webapp"MockServletContextServletContextWebApplicationContext

以下示例演示如何使用注释：@WebAppConfiguration

@ContextConfiguration
@WebAppConfiguration 
class WebAppTests {
    // class body...
}

若要覆盖默认值，可以使用隐式属性。两者和资源前缀是支持。如果未提供资源前缀，则假定路径为文件系统资源。下面的示例演示如何指定类路径资源：valueclasspath:file:

@ContextConfiguration
@WebAppConfiguration("classpath:test-web-resources") 
class WebAppTests {
    // class body...
}

请注意，必须在单个测试类或测试类中结合使用等级制度。有关更多详细信息，请参阅@WebAppConfigurationjavadoc。@WebAppConfiguration@ContextConfiguration

`@ContextHierarchy`

@ContextHierarchy是一个类级注释，用于定义集成测试的实例层次结构。应该是使用一个或多个实例的列表声明，每个实例定义上下文层次结构中的级别。以下示例演示了在单个测试类中的用法（也可以使用在测试类层次结构中）：ApplicationContext@ContextHierarchy@ContextConfiguration@ContextHierarchy@ContextHierarchy

@ContextHierarchy({
    @ContextConfiguration("/parent-config.xml"),
    @ContextConfiguration("/child-config.xml")
})
class ContextHierarchyTests {
    // class body...
}

@WebAppConfiguration
@ContextHierarchy({
    @ContextConfiguration(classes = AppConfig.class),
    @ContextConfiguration(classes = WebConfig.class)
})
class WebIntegrationTests {
    // class body...
}

如果需要合并或覆盖给定上下文级别的配置层次结构在测试类层次结构中，必须通过提供相同的值到属性在每一个对应的类层次结构中的级别。请参阅上下文层次结构和@ContextHierarchyjavadoc 有关进一步的示例。name@ContextConfiguration

`@ActiveProfiles`

@ActiveProfiles是一个类级注释，用于声明哪个 Bean 定义配置文件在加载 ANFOR 时应处于活动状态集成测试。ApplicationContext

以下示例指示配置文件应处于活动状态：dev

@ContextConfiguration
@ActiveProfiles("dev") 
class DeveloperTests {
    // class body...
}

以下示例指示配置文件和配置文件都应保持活跃：devintegration

@ContextConfiguration
@ActiveProfiles({"dev", "integration"}) 
class DeveloperIntegrationTests {
    // class body...
}

请参阅使用环境配置文件进行上下文配置、@Nested测试类配置和@ActiveProfilesjavadoc 以了解示例和更多详细信息。

`@TestPropertySource`

@TestPropertySource是可用于配置要添加到集合的属性文件和内联属性的位置在 for 已加载集成测试。PropertySourcesEnvironmentApplicationContext

下面的示例演示如何从类路径声明属性文件

@ContextConfiguration
@TestPropertySource("/test.properties") 
class MyIntegrationTests {
    // class body...
}

下面的示例演示如何声明内联属性：

@ContextConfiguration
@TestPropertySource(properties = { "timezone = GMT", "port: 4242" }) 
class MyIntegrationTests {
    // class body...
}

有关示例和更多详细信息，请参阅使用测试属性源进行上下文配置。

`@DynamicPropertySource`

@DynamicPropertySource是一个方法级注释，可用于注册要添加到集合中的动态属性已加载以进行集成测试。动态属性很有用当您事先不知道属性的价值时 - 例如，如果属性由外部资源管理，例如由Testcontainers项目管理的容器。PropertySourcesEnvironmentApplicationContext

下面的示例演示如何注册动态属性：

@ContextConfiguration
class MyIntegrationTests {

    static MyExternalServer server = // ...

    @DynamicPropertySource 
    static void dynamicProperties(DynamicPropertyRegistry registry) { 
        registry.add("server.port", server::getPort); 
    }

    // tests ...
}

有关更多详细信息，请参阅使用动态属性源进行上下文配置。

`@DirtiesContext`

@DirtiesContext表示底层弹簧已被在执行测试期间脏污（即测试修改或损坏了它某种方式 — 例如，通过更改单例 Bean 的状态）并且应该是闭。当应用程序上下文被标记为脏时，将从测试中删除它框架的缓存并关闭。因此，底层的 Spring 容器是为需要具有相同配置的上下文的任何后续测试重新生成元数据。ApplicationContext

您可以在相同的类或类层次结构。在这种情况下，标记为在任何此类注释方法之前或之后以及当前之前或之后都脏测试类，具体取决于配置和。@DirtiesContextApplicationContextmethodModeclassMode

以下示例说明了上下文何时会因各种配置方案：

在当前测试类之前，在类模式设置为的类上声明时。BEFORE_CLASS

@DirtiesContext(classMode = BEFORE_CLASS) 
class FreshContextTests {
    // some tests that require a new Spring container
}

在当前测试类之后，当在类模式设置为（即默认类模式）的类上声明时。AFTER_CLASS

@DirtiesContext 
class ContextDirtyingTests {
    // some tests that result in the Spring container being dirtied
}

在当前测试类中的每个测试方法之前，在具有类的类上声明时模式设置为BEFORE_EACH_TEST_METHOD.

@DirtiesContext(classMode = BEFORE_EACH_TEST_METHOD) 
class FreshContextTests {
    // some tests that require a new Spring container
}

在当前测试类中的每个测试方法之后，当在具有类的类上声明时模式设置为AFTER_EACH_TEST_METHOD.

@DirtiesContext(classMode = AFTER_EACH_TEST_METHOD) 
class ContextDirtyingTests {
    // some tests that result in the Spring container being dirtied
}

在当前测试之前，在方法模式设置为的方法上声明时。BEFORE_METHOD

@DirtiesContext(methodMode = BEFORE_METHOD) 
@Test
void testProcessWhichRequiresFreshAppCtx() {
    // some logic that requires a new Spring container
}

在当前测试之后，当在方法上声明方法模式设置为（即默认方法模式）时。AFTER_METHOD

@DirtiesContext 
@Test
void testProcessWhichDirtiesAppCtx() {
    // some logic that results in the Spring container being dirtied
}

如果在上下文配置为上下文一部分的测试中使用层次结构，您可以使用标志来控制如何上下文缓存将被清除。默认情况下，使用穷举算法来清除上下文缓存，不仅包括当前级别，还包括所有其他上下文共享当前测试通用的祖先上下文的层次结构。驻留在共同祖先的子层次结构中的所有实例上下文将从上下文缓存中删除并关闭。如果穷举算法是对于特定用例的矫枉过正，您可以指定更简单的当前电平算法，如以下示例所示。@DirtiesContext@ContextHierarchyhierarchyModeApplicationContext

@ContextHierarchy({
    @ContextConfiguration("/parent-config.xml"),
    @ContextConfiguration("/child-config.xml")
})
class BaseTests {
    // class body...
}

class ExtendedTests extends BaseTests {

    @Test
    @DirtiesContext(hierarchyMode = CURRENT_LEVEL) 
    void test() {
        // some logic that results in the child context being dirtied
    }
}

有关 theandalgorithms 的更多详细信息，请参阅DirtiesContext.HierarchyModejavadoc。EXHAUSTIVECURRENT_LEVEL

`@TestExecutionListeners`

@TestExecutionListeners用于注册特定测试类的侦听器，其子类及其嵌套类。如果您希望全局注册侦听器，则应通过测试执行侦听器配置中所述的自动发现机制注册它。

下面的示例演示如何注册两个实现：TestExecutionListener

@ContextConfiguration
@TestExecutionListeners({CustomTestExecutionListener.class, AnotherTestExecutionListener.class}) 
class CustomTestExecutionListenerTests {
    // class body...
}

默认情况下，支持从超类或封闭类。有关示例和更多详细信息，请参阅@Nested测试类配置和 javadoc @TestExecutionListeners。如果您发现需要切换返回到使用默认实现，请参阅注释在注册TestExecutionListener实现中。@TestExecutionListenersTestExecutionListener

`@RecordApplicationEvents`

@RecordApplicationEvents是一个类级注释，用于指示Spring TestContext 框架记录在执行单个测试期间发布的所有应用程序事件。ApplicationContext

记录的事件可以通过测试中的API访问。ApplicationEvents

有关示例和更多详细信息，请参阅应用程序事件和 @RecordApplicationEventsjavadoc。

`@Commit`

@Commit指示事务测试方法的事务应为在测试方法完成后提交。您可以用作直接替换 for以更明确地传达代码的意图。类似，也可以声明为类级或方法级注解。@Commit@Rollback(false)@Rollback@Commit

以下示例演示如何使用注释：@Commit

@Commit 
@Test
void testProcessWithoutRollback() {
    // ...
}

`@Rollback`

@Rollback指示事务测试方法的事务是否应为测试方法完成后回滚。如果，事务已滚动返回。否则，将提交事务（另请参阅@Commit）。春季集成测试的回滚 TestContext Framework 默认为未显式声明的 ifis。truetrue@Rollback

当声明为类级注释时，定义默认回滚测试类层次结构中所有测试方法的语义。当声明为方法级标注，定义特定测试的回滚语义方法，可能覆盖类级语言。@Rollback@Rollback@Rollback@Commit

以下示例导致测试方法的结果不回滚（即结果提交到数据库）：

@Rollback(false) 
@Test
void testProcessWithoutRollback() {
    // ...
}

`@BeforeTransaction`

@BeforeTransaction指示注释方法应在事务已启动，对于已配置为在使用 Spring'sannotation.methods 的事务不需要并且可以在基于 Java 8 的接口缺省值上声明方法。void@Transactional@BeforeTransactionpublic

以下示例演示如何使用注释：@BeforeTransaction

@BeforeTransaction 
void beforeTransaction() {
    // logic to be run before a transaction is started
}

`@AfterTransaction`

@AfterTransaction指示注释方法应在事务已结束，对于已配置为在使用 Spring'sannotation.methods 的事务不需要并且可以在基于 Java 8 的接口缺省值上声明方法。void@Transactional@AfterTransactionpublic

@AfterTransaction 
void afterTransaction() {
    // logic to be run after a transaction has ended
}

`@Sql`

@Sql用于批注测试类或测试方法，以配置要运行的 SQL 脚本在集成测试期间针对给定数据库。以下示例演示如何使用它：

@Test
@Sql({"/test-schema.sql", "/test-user-data.sql"}) 
void userTest() {
    // run code that relies on the test schema and test data
}

有关更多详细信息，请参阅使用 @Sql 以声明方式执行 SQL 脚本。

`@SqlConfig`

@SqlConfig定义用于确定如何分析和运行 SQL 脚本的元数据配置了注释。以下示例演示如何使用它：@Sql

@Test
@Sql(
    scripts = "/test-user-data.sql",
    config = @SqlConfig(commentPrefix = "`", separator = "@@") 
)
void userTest() {
    // run code that relies on the test data
}

`@SqlMergeMode`

@SqlMergeMode用于批注测试类或测试方法，以配置是否方法级声明与类级声明合并。未在测试类或测试方法上声明 ifis，合并模式将默认使用。使用 mode，方法级声明将有效地重写类级声明。@Sql@Sql@SqlMergeModeOVERRIDEOVERRIDE@Sql@Sql

请注意，方法级声明覆盖类级声明。@SqlMergeMode

下面的示例演示如何在类级别使用。@SqlMergeMode

@SpringJUnitConfig(TestConfig.class)
@Sql("/test-schema.sql")
@SqlMergeMode(MERGE) 
class UserTests {

    @Test
    @Sql("/user-test-data-001.sql")
    void standardUserProfile() {
        // run code that relies on test data set 001
    }
}

下面的示例演示如何在方法级别使用。@SqlMergeMode

@SpringJUnitConfig(TestConfig.class)
@Sql("/test-schema.sql")
class UserTests {

    @Test
    @Sql("/user-test-data-001.sql")
    @SqlMergeMode(MERGE) 
    void standardUserProfile() {
        // run code that relies on test data set 001
    }
}

`@SqlGroup`

@SqlGroup是聚合多个注释的容器注释。您可以本机用于声明多个嵌套注释，也可以使用它结合Java 8对可重复注释的支持，其中可以在同一类或方法上声明多次，隐式生成此容器注解。以下示例演示如何声明 SQL 组：@Sql@SqlGroup@Sql@Sql

@Test
@SqlGroup({ 
    @Sql(scripts = "/test-schema.sql", config = @SqlConfig(commentPrefix = "`")),
    @Sql("/test-user-data.sql")
)}
void userTest() {
    // run code that uses the test schema and test data
}

3.4.2. 标准注释支持

以下注释支持所有配置的标准语义 Spring TestContext Framework。请注意，这些注释并非特定于测试并且可以在 Spring 框架中的任何位置使用。

@Autowired
@Qualifier
@Value
@Resource（jakarta.annotation）如果 JSR-250 存在
@ManagedBean（jakarta.annotation）如果 JSR-250 存在
@Inject（jakarta.inject）如果 JSR-330 存在
@Named（jakarta.inject）如果 JSR-330 存在
@PersistenceContext（jakarta.persistence）如果 JPA 存在
@PersistenceUnit（jakarta.persistence）如果 JPA 存在
@Transactional（org.springframework.transaction.annotation）具有有限的属性支持

3.4.3. 春季 JUnit 4 测试注释

以下注释仅在与SpringRunner、Spring 的 JUnit 4 结合使用时受支持。规则，或Spring 的 JUnit 4 支持类：

@IfProfileValue
@ProfileValueSourceConfiguration
@Timed
@Repeat

`@IfProfileValue`

@IfProfileValue指示为特定测试启用了带注释的测试环境。如果配置返回匹配前提是，测试已启用。否则，测试将被禁用，并且实际上，忽视。ProfileValueSourcevaluename

您可以在类级别、方法级别或两者级别申请。对于任何该类或其子类中的方法。具体而言，如果测试是在类级别和方法级别启用。缺少意味着隐式启用测试。这类似于 JUnit 4'sannotation 的语义，只是 Always 的存在会禁用测试。@IfProfileValue@IfProfileValue@IfProfileValue@Ignore@Ignore

以下示例显示具有注释的测试：@IfProfileValue

@IfProfileValue(name="java.vendor", value="Oracle Corporation") 
@Test
public void testProcessWhichRunsOnlyOnOracleJvm() {
    // some logic that should run only on Java VMs from Oracle Corporation
}

仅当 Java 供应商是“Oracle 公司”时，才运行此测试。

或者，您可以使用（带有语义）的列表进行配置，以实现对JUnit 4环境中测试组的类似TestNG的支持。请考虑以下示例：@IfProfileValuevaluesOR

@IfProfileValue(name="test-groups", values={"unit-tests", "integration-tests"}) 
@Test
public void testProcessWhichRunsForUnitOrIntegrationTestGroups() {
    // some logic that should run only for unit and integration test groups
}

针对单元测试和集成测试运行此测试。

`@ProfileValueSourceConfiguration`

@ProfileValueSourceConfiguration是指定类型的类级注释 of在检索通过注释配置的配置文件值时使用。未声明测试，默认使用。下面的示例演示如何用：ProfileValueSource@IfProfileValue@ProfileValueSourceConfigurationSystemProfileValueSource@ProfileValueSourceConfiguration

@ProfileValueSourceConfiguration(CustomProfileValueSource.class) 
public class CustomProfileValueSourceTests {
    // class body...
}

使用自定义配置文件值源。

`@Timed`

@Timed指示带批注的测试方法必须在指定的时间段（以毫秒为单位）。如果文本执行时间超过指定时间期间，测试失败。

时间段包括运行测试方法本身、测试的任何重复（参见）以及测试夹具的任何设置或拆卸。以下示例显示了如何使用它：@Repeat

@Timed(millis = 1000) 
public void testProcessWithOneSecondTimeout() {
    // some logic that should not take longer than 1 second to run
}

将测试的时间段设置为一秒。

Spring'sannotation 与 JUnit 4 的支持具有不同的语义。具体来说，由于 JUnit 4 处理测试执行超时的方式（即，通过在单独的测试方法中执行），如果测试时间过长，则抢先使测试失败。春天，在另一边手，不会先发制人地使测试失败，而是等待测试完成在失败之前。@Timed@Test(timeout=…)Thread@Test(timeout=…)@Timed

`@Repeat`

@Repeat指示必须重复运行带批注的测试方法。的数量在注释中指定要运行测试方法的时间。

要重复的执行范围包括测试方法本身的执行以及测试夹具的任何设置或拆卸。当与SpringMethodRule 一起使用时，范围还包括通过实现准备测试实例。这以下示例显示了如何使用注释：TestExecutionListener@Repeat

@Repeat(10) 
@Test
public void testProcessRepeatedly() {
    // ...
}

重复此测试十次。

3.4.4. 春季 JUnit 木星测试注释

当与SpringExtension 和 JUnitJupiter 结合使用时，支持以下注释。（即 JUnit 5 中的编程模型）：

@SpringJUnitConfig
@SpringJUnitWebConfig
@TestConstructor
@NestedTestConfiguration
@EnabledIf
@DisabledIf

`@SpringJUnitConfig`

@SpringJUnitConfig是一个组合的注释，它结合了 JUnit 木星与 Spring TestContext Framework。它可以在类级别用作插入式替换。关于配置选项，唯一的该组件之间的区别类可以用属性 in 声明。@ExtendWith(SpringExtension.class)@ContextConfiguration@ContextConfiguration@ContextConfiguration@SpringJUnitConfigvalue@SpringJUnitConfig

下面的示例演示如何使用注释来指定配置类：@SpringJUnitConfig

@SpringJUnitConfig(TestConfig.class) 
class ConfigurationClassJUnitJupiterSpringTests {
    // class body...
}

指定配置类。

下面的示例演示如何使用注释来指定配置文件的位置：@SpringJUnitConfig

@SpringJUnitConfig(locations = "/test-config.xml") 
class XmlJUnitJupiterSpringTests {
    // class body...
}

指定配置文件的位置。

有关更多详细信息，请参阅上下文管理以及 javadoc@SpringJUnitConfig 和更多详细信息。@ContextConfiguration

`@SpringJUnitWebConfig`

@SpringJUnitWebConfig是一个组合的注释，结合了 JUnit Jupiter 和 Spring TestContext 框架。您可以在课堂上使用它级别作为直接替代品。关于配置选项，唯一的区别是您可以使用属性 in 声明组件类。此外，您还可以通过使用属性 in 来覆盖属性 fromonly。@ExtendWith(SpringExtension.class)@ContextConfiguration@WebAppConfiguration@ContextConfiguration@WebAppConfiguration@ContextConfiguration@SpringJUnitWebConfigvalue@SpringJUnitWebConfigvalue@WebAppConfigurationresourcePath@SpringJUnitWebConfig

下面的示例演示如何使用注释来指定配置类：@SpringJUnitWebConfig

@SpringJUnitWebConfig(TestConfig.class) 
class ConfigurationClassJUnitJupiterSpringWebTests {
    // class body...
}

指定配置类。

下面的示例演示如何使用注释来指定配置文件的位置：@SpringJUnitWebConfig

@SpringJUnitWebConfig(locations = "/test-config.xml") 
class XmlJUnitJupiterSpringWebTests {
    // class body...
}

指定配置文件的位置。

有关更多详细信息，请参阅上下文管理以及 javadoc 的 @SpringJUnitWebConfig，@ContextConfiguration 和 @WebAppConfiguration。

`@TestConstructor`

@TestConstructor是一个类型级注释，用于配置参数的测试类构造函数是从测试中的组件自动连线的。ApplicationContext

Ifis 在测试类（默认测试）上不存在或元存在 将使用构造函数自动连线模式。有关如何更改的详细信息，请参阅以下提示默认模式。但是，请注意，本地声明构造函数优先于两者和默认模式。@TestConstructor@Autowired@TestConstructor

`@NestedTestConfiguration`

@NestedTestConfiguration是类型级注释，用于配置弹簧测试配置注释在封闭的类层次结构中处理对于内部测试类。

Ifis 在测试类中不存在或元存在，在其超类型层次结构，或在其封闭类层次结构中，默认封闭类层次结构 将使用配置继承模式。有关如何的详细信息，请参阅下面的提示更改默认模式。@NestedTestConfiguration

Spring TestContext 框架尊重语义以下注释。@NestedTestConfiguration

@BootstrapWith
@ContextConfiguration
@WebAppConfiguration
@ContextHierarchy
@ActiveProfiles
@TestPropertySource
@DynamicPropertySource
@DirtiesContext
@TestExecutionListeners
@RecordApplicationEvents
@Transactional
@Commit
@Rollback
@Sql
@SqlConfig
@SqlMergeMode
@TestConstructor

有关示例和进一步内容，请参阅@Nested测试类配置详。

`@EnabledIf`

@EnabledIf用于指示带注释的 JUnit 木星测试类或测试方法已启用，如果提供的评估结果为，则应运行。具体而言，如果表达式的计算结果等于（忽略大小写），则启用测试。在类级别应用时，所有测试方法默认情况下，该类中也会自动启用。expressiontrueBoolean.TRUEStringtrue

表达式可以是以下任何一种：

弹簧表达式语言（SpEL）表达式。例如：@EnabledIf("#{systemProperties['os.name'].toLowerCase().contains('mac')}")
春季环境中可用属性的占位符。例如：@EnabledIf("${smoke.tests.enabled}")
文本文字。例如：@EnabledIf("true")

但请注意，文本文本不是动态解析的结果属性占位符的实用价值为零，因为等价于逻辑上毫无意义。@EnabledIf("false")@Disabled@EnabledIf("true")

您可以用作元注释来创建自定义组合注释。为例如，您可以创建自定义注释，如下所示：@EnabledIf@EnabledOnMac

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@EnabledIf(
    expression = "#{systemProperties['os.name'].toLowerCase().contains('mac')}",
    reason = "Enabled on Mac OS"
)
public @interface EnabledOnMac {}

`@DisabledIf`

@DisabledIf用于指示带注释的JUnit Jupiter测试类或测试方法已禁用，如果提供的计算结果为，则不应运行该方法。具体来说，如果表达式的计算结果等于到（忽略大小写），测试被禁用。在类级别应用时，所有该类中的测试方法也会自动禁用。expressiontrueBoolean.TRUEStringtrue

表达式可以是以下任何一种：

弹簧表达式语言（SpEL）表达式。例如：@DisabledIf("#{systemProperties['os.name'].toLowerCase().contains('mac')}")
春季环境中可用属性的占位符。例如：@DisabledIf("${smoke.tests.disabled}")
文本文字。例如：@DisabledIf("true")

但请注意，文本文本不是动态解析的结果属性占位符的实用价值为零，因为等价于逻辑上毫无意义。@DisabledIf("true")@Disabled@DisabledIf("false")

您可以用作元注释来创建自定义组合注释。为例如，您可以创建自定义注释，如下所示：@DisabledIf@DisabledOnMac

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@DisabledIf(
    expression = "#{systemProperties['os.name'].toLowerCase().contains('mac')}",
    reason = "Disabled on Mac OS"
)
public @interface DisabledOnMac {}

3.4.5. 测试的元注释支持

您可以使用大多数与测试相关的注释作为元注释来创建自定义组合注释并减少测试套件中的配置重复。

您可以将以下每个内容用作与TestContext 框架结合使用的元注释。

@BootstrapWith
@ContextConfiguration
@ContextHierarchy
@ActiveProfiles
@TestPropertySource
@DirtiesContext
@WebAppConfiguration
@TestExecutionListeners
@Transactional
@BeforeTransaction
@AfterTransaction
@Commit
@Rollback
@Sql
@SqlConfig
@SqlMergeMode
@SqlGroup
@Repeat （仅在 JUnit 4 上受支持）
@Timed （仅在 JUnit 4 上受支持）
@IfProfileValue （仅在 JUnit 4 上受支持）
@ProfileValueSourceConfiguration （仅在 JUnit 4 上受支持）
@SpringJUnitConfig （仅在JUnit Jupiter上支持）
@SpringJUnitWebConfig （仅在JUnit Jupiter上支持）
@TestConstructor （仅在JUnit Jupiter上支持）
@NestedTestConfiguration （仅在JUnit Jupiter上支持）
@EnabledIf （仅在JUnit Jupiter上支持）
@DisabledIf （仅在JUnit Jupiter上支持）

请考虑以下示例：

@RunWith(SpringRunner.class)
@ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"})
@ActiveProfiles("dev")
@Transactional
public class OrderRepositoryTests { }

@RunWith(SpringRunner.class)
@ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"})
@ActiveProfiles("dev")
@Transactional
public class UserRepositoryTests { }

如果我们发现我们在基于 JUnit 4 的配置中重复上述配置测试套件，我们可以通过引入自定义组合注释来减少重复它集中了 Spring 的通用测试配置，如下所示：

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"})
@ActiveProfiles("dev")
@Transactional
public @interface TransactionalDevTestConfig { }

然后我们可以使用我们的自定义注释来简化配置各个基于 JUnit 4 的测试类，如下所示：@TransactionalDevTestConfig

@RunWith(SpringRunner.class)
@TransactionalDevTestConfig
public class OrderRepositoryTests { }

@RunWith(SpringRunner.class)
@TransactionalDevTestConfig
public class UserRepositoryTests { }

如果我们编写使用 JUnit Jupiter 的测试，我们可以进一步减少代码重复，因为 JUnit 5 中的注释也可以用作元注释。请考虑以下事项例：

@ExtendWith(SpringExtension.class)
@ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"})
@ActiveProfiles("dev")
@Transactional
class OrderRepositoryTests { }

@ExtendWith(SpringExtension.class)
@ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"})
@ActiveProfiles("dev")
@Transactional
class UserRepositoryTests { }

如果我们发现我们在 JUnit 中重复上述配置基于 Jupiter 的测试套件，我们可以通过引入自定义组合来减少重复集中了 Spring 和 JUnit Jupiter 的通用测试配置的注释，如下：

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@ExtendWith(SpringExtension.class)
@ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"})
@ActiveProfiles("dev")
@Transactional
public @interface TransactionalDevTestConfig { }

然后我们可以使用我们的自定义注释来简化基于 JUnit Jupiter 的各个测试类的配置，如下所示：@TransactionalDevTestConfig

@TransactionalDevTestConfig
class OrderRepositoryTests { }

@TransactionalDevTestConfig
class UserRepositoryTests { }

由于JUnit Jupiter支持使用,,, 和其他作为元注释，您还可以在测试方法级别。例如，如果我们希望创建一个组合的注释来自JUnit Jupiter的theandannotations with theannotation from Spring，我们可以创建anannotation，如遵循：@Test@RepeatedTestParameterizedTest@Test@Tag@Transactional@TransactionalIntegrationTest

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Transactional
@Tag("integration-test") // org.junit.jupiter.api.Tag
@Test // org.junit.jupiter.api.Test
public @interface TransactionalIntegrationTest { }

然后我们可以使用我们的自定义注释来简化基于JUnit Jupiter的测试方法的配置如下：@TransactionalIntegrationTest

@TransactionalIntegrationTest
void saveOrder() { }

@TransactionalIntegrationTest
void deleteOrder() { }

有关更多详细信息，请参阅Spring 注释编程模型wiki 页面。

3.5. 弹簧测试上下文框架

Spring TestContext Framework（位于软件包中）提供了通用的、注释驱动的单元和集成测试支持，即与正在使用的测试框架无关。TestContext 框架还放置了一个很棒的处理约定的重要性而不是配置，具有合理的默认值，您可以通过基于注释的配置进行覆盖。org.springframework.test.context

除了通用测试基础设施之外，TestContext 框架还提供显式支持 JUnit 4、JUnit Jupiter（AKA JUnit 5）和 TestNG。对于 JUnit 4 和 TestNG，Spring提供支持类。此外，春天提供了一个定制 JUnitand custom JUnitfor JUnit 4 and a customfor JUnit 木星，让你写所谓的POJO测试类。POJO测试类不是需要扩展特定的类层次结构，例如支持类。abstractRunnerRulesExtensionabstract

以下部分概述了 TestContext 框架的内部结构。如果您只对使用框架感兴趣，而对扩展它不感兴趣使用您自己的自定义侦听器或自定义加载程序，请随时直接转到配置（上下文管理、依赖注入、事务管理）、支持类和注释支持部分。

3.5.1. 关键抽象

框架的核心由类和，和接口组成。为每个测试类创建的 Ais（例如，用于执行 JUnit Jupiter 中单个测试类中的所有测试方法）。这反过来，管理 A 保存当前测试的上下文。还随着测试的进行而更新状态并委托给实现，这些实现检测实际通过提供依赖项注入、管理事务等来测试执行。负责加载给定测试的 AIS .class。请参阅javadoc和弹簧测试套件，以获取更多信息和各种实现的示例。TestContextManagerTestContextTestExecutionListenerSmartContextLoaderTestContextManagerTestContextManagerTestContextTestContextManagerTestContextTestExecutionListenerSmartContextLoaderApplicationContext

`TestContext`

TestContext封装运行测试的上下文（与使用中的实际测试框架），并提供上下文管理和缓存支持它负责的测试实例。该还委托给 ato 加载 anif 请求。TestContextSmartContextLoaderApplicationContext

`TestContextManager`

TestContextManager是 Spring TestContext 框架的主要入口点，并且是负责管理单个和信号事件到每个注册在明确定义的测试执行点：TestContextTestExecutionListener

在特定测试框架的任何“课前”或“所有”方法之前。
测试实例后处理。
在特定测试框架的任何“之前”或“之前”方法之前。
在执行测试方法之前，但在测试设置之后。
在执行测试方法后，但在测试拆卸之前立即进行。
在特定测试框架的任何“之后”或“之后”方法之后。
在特定测试框架的任何“课后”或“毕竟”方法之后。

`TestExecutionListener`

TestExecutionListener定义用于响应发布的测试执行事件的 API 侦听器注册的位置。请参阅TestExecutionListener配置。TestContextManager

上下文加载器

ContextLoader是一个策略接口，用于加载由Spring TestContext Framework管理的集成测试。您应该实现而不是此接口来提供对组件类的支持，活动 Bean 定义概要文件、测试属性源、上下文层次结构和支持。ApplicationContextSmartContextLoaderWebApplicationContext

SmartContextLoader是取代原始的最小 SPI。具体来说，acan 选择处理资源位置、组件类或上下文初始值设定项。此外，acan 在它加载的上下文。ContextLoaderContextLoaderSmartContextLoaderSmartContextLoader

Spring 提供了以下实现：

DelegatingSmartContextLoader：两个默认加载器之一，它在内部委托给 an、a 或 a，具体取决于为测试类或是否存在默认位置或默认配置类。仅当 Groovy 位于类路径上时，才会启用 Groovy 支持。AnnotationConfigContextLoaderGenericXmlContextLoaderGenericGroovyXmlContextLoader
WebDelegatingSmartContextLoader：两个默认加载器之一，它在内部委派到 an、a 或 a，具体取决于声明的配置测试类或是否存在默认位置或默认配置类。仅 if 存在于测试类。仅当 Groovy 位于类路径上时，才会启用 Groovy 支持。AnnotationConfigWebContextLoaderGenericXmlWebContextLoaderGenericGroovyXmlWebContextLoaderContextLoader@WebAppConfiguration
AnnotationConfigContextLoader：从组件加载标准类。ApplicationContext
AnnotationConfigWebContextLoader：从组件加载类。WebApplicationContext
GenericGroovyXmlContextLoader：加载标准源资源作为 Groovy 脚本或 XML 配置文件的位置。ApplicationContext
GenericGroovyXmlWebContextLoader：从资源加载作为 Groovy 脚本或 XML 配置文件的位置。WebApplicationContext
GenericXmlContextLoader：从 XML 资源加载标准地点。ApplicationContext
GenericXmlWebContextLoader：从 XML 资源加载地点。WebApplicationContext

3.5.2. 引导测试上下文框架

Spring TestContext Framework 内部的默认配置是足以满足所有常见用例。但是，有时开发团队或第三方框架想要更改默认值，实现 customor，扩充默认的 OF 和实现集，等等。为对TestContext框架如何运行的这种低级控制，Spring提供了一个引导策略。ContextLoaderTestContextContextCacheContextCustomizerFactoryTestExecutionListener

TestContextBootstrapper定义用于引导测试上下文框架的 SPI。AI 由 the（英语）用于加载当前测试的实现并构建它所管理的。您可以为测试类（或测试类层次结构）直接使用或作为元注释。如果未使用显式配置引导程序，则使用引导程序或 the，具体取决于是否存在。TestContextBootstrapperTestContextManagerTestExecutionListenerTestContext@BootstrapWith@BootstrapWithDefaultTestContextBootstrapperWebTestContextBootstrapper@WebAppConfiguration

由于SPI将来可能会发生变化（以适应新要求），我们强烈建议实现者不要实现此接口直接但更像是延伸其混凝土之一子类代替。TestContextBootstrapperAbstractTestContextBootstrapper

3.5.3.配置`TestExecutionListener`

Spring 提供了以下已注册的实现默认情况下，完全按以下顺序排列：TestExecutionListener

ServletTestExecutionListener：为 a 配置 Servlet API 模拟。WebApplicationContext
DirtiesContextBeforeModesTestExecutionListener：处理“之前”模式的注释。@DirtiesContext
ApplicationEventsTestExecutionListener：提供对应用程序事件的支持。
DependencyInjectionTestExecutionListener：为测试提供依赖注入实例。
DirtiesContextTestExecutionListener：处理的注释 “之后”模式。@DirtiesContext
TransactionalTestExecutionListener：提供事务测试执行默认回滚语义。
SqlScriptsTestExecutionListener：运行使用注释配置的 SQL 脚本。@Sql
EventPublishingTestExecutionListener：将测试执行事件发布到测试（请参阅测试执行事件）。ApplicationContext

注册实现`TestExecutionListener`

您可以为测试类显式注册实现，其子类及其嵌套类（通过使用注释）。有关详细信息和示例，请参阅注释支持和 javadoc@TestExecutionListeners。TestExecutionListener@TestExecutionListeners

自动发现默认实现`TestExecutionListener`

注册通过使用实现是适用于在有限测试方案中使用的自定义侦听器。但是，它可以如果需要在整个测试套件中使用自定义侦听器，则会变得很麻烦。这通过支持通过机制自动发现默认实现来解决此问题。TestExecutionListener@TestExecutionListenersTestExecutionListenerSpringFactoriesLoader

具体来说，该模块在其属性文件。第三方框架和开发人员可以将自己的实现贡献给默认列表侦听器通过自己的属性以相同的方式文件。spring-testTestExecutionListenerorg.springframework.test.context.TestExecutionListenerMETA-INF/spring.factoriesTestExecutionListenerMETA-INF/spring.factories

排序实现`TestExecutionListener`

当 TestContext 框架发现默认实现时通过上述机制，实例化的侦听器使用 Spring's，它遵循 Spring 的接口和排序注释，以及 Spring 实现提供的所有默认实现适当的值。因此，第三方框架和开发人员应确保它们的默认实现以正确的顺序注册通过实现或声明。有关核心默认实现的方法，请参阅 javadoc 以获取有关详细信息的内容值分配给每个核心侦听器。TestExecutionListenerSpringFactoriesLoaderAnnotationAwareOrderComparatorOrdered@OrderAbstractTestExecutionListenerTestExecutionListenerOrderedTestExecutionListenerOrdered@OrdergetOrder()TestExecutionListener

合并实现`TestExecutionListener`

如果海关注册通过，未注册默认侦听器。在最常见的测试场景中，这有效地强制开发人员手动声明除任何自定义之外的所有默认侦听器听众。下面的清单演示了这种配置方式：TestExecutionListener@TestExecutionListeners

@ContextConfiguration
@TestExecutionListeners({
    MyCustomTestExecutionListener.class,
    ServletTestExecutionListener.class,
    DirtiesContextBeforeModesTestExecutionListener.class,
    DependencyInjectionTestExecutionListener.class,
    DirtiesContextTestExecutionListener.class,
    TransactionalTestExecutionListener.class,
    SqlScriptsTestExecutionListener.class
})
class MyTest {
    // class body...
}

这种方法的挑战在于它要求开发人员确切地知道默认情况下注册哪些侦听器。此外，默认侦听器集可以从一个版本到另一个版本的变化 — 例如，是在 Spring Framework 4.1 中引入，并在 Spring Framework 4.2 中引入。此外，像Spring这样的第三方框架引导和 Spring 安全性通过使用上述自动发现机制注册自己的默认实现。SqlScriptsTestExecutionListenerDirtiesContextBeforeModesTestExecutionListenerTestExecutionListener

为了避免必须知道并重新声明所有缺省侦听器，可以将属性 ofto。指示本地声明的侦听器应与默认侦听器。合并算法可确保从列表，并且根据语义对合并侦听器的结果集进行排序的，如排序TestExecutionListener实现中所述。如果侦听器实现者被注释，它可能会影响与默认值合并的位置。否则，本地声明的侦听器在合并时追加到默认侦听器列表中。mergeMode@TestExecutionListenersMergeMode.MERGE_WITH_DEFAULTSMERGE_WITH_DEFAULTSAnnotationAwareOrderComparatorOrdered@Order

例如，如果上一个示例中的类将其值（例如，）配置为小于（恰好是）的顺序，然后可以自动与列表合并前面的默认值，前面的示例可以替换为以下内容：MyCustomTestExecutionListenerorder500ServletTestExecutionListener1000MyCustomTestExecutionListenerServletTestExecutionListener

@ContextConfiguration
@TestExecutionListeners(
    listeners = MyCustomTestExecutionListener.class,
    mergeMode = MERGE_WITH_DEFAULTS
)
class MyTest {
    // class body...
}

3.5.4. 应用程序事件

从 Spring Framework 5.3.3 开始，TestContext 框架支持记录中发布的应用程序事件，以便可以针对这些事件执行断言测试。在执行单个测试期间发布的所有事件都通过以下方式提供该 API，它允许您将事件处理为 a。ApplicationContextApplicationEventsjava.util.Stream

要在测试中使用，请执行以下操作。ApplicationEvents

确保您的测试类带有注释或元注释@RecordApplicationEvents。
确保已注册。但请注意，这是默认注册的，只需要如果您具有不包括默认侦听器的自定义配置，则手动注册。ApplicationEventsTestExecutionListenerApplicationEventsTestExecutionListener@TestExecutionListeners
注释 typeWith 字段，并在测试和生命周期方法（例如 JUnit Jupiter 中的 andmethods）中使用该实例。ApplicationEvents@AutowiredApplicationEvents@BeforeEach@AfterEach

当使用SpringExtension for JUnit Jupiter 时，你可以声明一个方法类型参数在测试或生命周期方法中作为替代到安菲尔德的测试课。ApplicationEvents@Autowired

以下测试类使用 for JUnit Jupiter 和AssertJ来断言应用程序事件的类型在 Spring 管理的组件中调用方法时发布：SpringExtension

@SpringJUnitConfig(/* ... */)
@RecordApplicationEvents 
class OrderServiceTests {

    @Autowired
    OrderService orderService;

    @Autowired
    ApplicationEvents events; 

    @Test
    void submitOrder() {
        // Invoke method in OrderService that publishes an event
        orderService.submitOrder(new Order(/* ... */));
        // Verify that an OrderSubmitted event was published
        long numEvents = events.stream(OrderSubmitted.class).count(); 
        assertThat(numEvents).isEqualTo(1);
    }
}

用注释测试类。`@RecordApplicationEvents`
注入当前测试的实例。`ApplicationEvents`
使用 API 计算发布了多少事件。`ApplicationEvents``OrderSubmitted`

请参阅ApplicationEventsjavadoc以获取有关 API 的更多详细信息。ApplicationEvents

3.5.5. 测试执行事件

Spring Framework 5.2 中引入的实现自定义的替代方法。组件在 test'scan 侦听以下事件，每个事件对应于 API 中的一个方法。EventPublishingTestExecutionListenerTestExecutionListenerApplicationContextEventPublishingTestExecutionListenerTestExecutionListener

BeforeTestClassEvent
PrepareTestInstanceEvent
BeforeTestMethodEvent
BeforeTestExecutionEvent
AfterTestExecutionEvent
AfterTestMethodEvent
AfterTestClassEvent

这些事件可能由于各种原因而被消耗，例如重置模拟 bean 或跟踪测试执行。使用测试执行事件而不是实现测试执行事件的一个优点测试执行事件可由任何春豆在测试中注册，此类豆类可能会受益直接来自依赖注入等功能。在相比之下，AI不是豆子。TestExecutionListenerApplicationContextApplicationContextTestExecutionListenerApplicationContext

为了监听测试执行事件，Spring Bean 可以选择实现接口。或者，侦听器方法可以注释并配置为侦听其中之一上面列出的特定事件类型（请参阅基于注释的事件侦听器）。由于这种方法的流行，Spring 提供了以下专用注释来简化测试执行事件侦听器的注册。这些批注驻留在包中。org.springframework.context.ApplicationListener@EventListener@EventListenerorg.springframework.test.context.event.annotation

@BeforeTestClass
@PrepareTestInstance
@BeforeTestMethod
@BeforeTestExecution
@AfterTestExecution
@AfterTestMethod
@AfterTestClass

异常处理

默认情况下，如果测试执行事件侦听器在使用事件，该异常将传播到正在使用的基础测试框架（例如 JUnit 或 TestNG）。例如，如果消耗导致异常，相应的测试方法将因异常而失败。在相反，如果异步测试执行事件侦听器引发异常，则异常不会传播到基础测试框架。有关更多详细信息异步异常处理，请参阅类级 Javadoc 了解。BeforeTestMethodEvent@EventListener

异步侦听器

如果希望特定的测试执行事件侦听器异步处理事件，您可以使用 Spring 的常规@Async支持。有关更多详细信息，请参阅类级 javadoc。@EventListener

3.5.6. 上下文管理

每个都为测试实例提供上下文管理和缓存支持它对此负责。测试实例不会自动接收对配置。但是，如果测试类实现了接口，则提供了对到测试实例。请注意，并实现并且因此，提供对自动的访问。TestContextApplicationContextApplicationContextAwareApplicationContextAbstractJUnit4SpringContextTestsAbstractTestNGSpringContextTestsApplicationContextAwareApplicationContext

使用 TestContext 框架的测试类不需要扩展任何特定的类或实现特定接口以配置其应用程序上下文。相反配置是通过在班级级别。如果测试类未显式声明应用程序上下文资源位置或组件类，配置确定如何加载来自默认位置或默认配置类的上下文。除了上下文资源位置和组件类，还可以配置应用程序上下文通过应用程序上下文初始值设定项。@ContextConfigurationContextLoader

以下各节解释了如何使用 Spring'sannotation 来通过使用 XML 配置文件、Groovy 脚本、组件类（通常为类）或上下文初始值设定项。或者，您可以实现和配置自己的自定义高级用例。@ContextConfigurationApplicationContext@ConfigurationSmartContextLoader

使用 XML 资源进行上下文配置
使用时髦脚本进行上下文配置
使用组件类进行上下文配置
混合 XML、时髦脚本和组件类
使用上下文初始值设定项进行上下文配置
上下文配置继承
使用环境配置文件进行上下文配置
使用测试属性源进行上下文配置
使用动态属性源进行上下文配置
加载Web 应用程序上下文
上下文缓存
上下文层次结构

使用 XML 资源进行上下文配置

若要使用 XML 配置文件加载测试，请批注您的测试类与并配置属性一个数组，包含 XML 配置元数据的资源位置。平原或相对路径（例如，）被视为类路径资源，即相对于在其中定义测试类的包。以斜杠开头的路径被视为绝对类路径位置（例如，）。一个表示资源 URL（即前缀为,,,等的路径）的路径按原样使用。ApplicationContext@ContextConfigurationlocationscontext.xml/org/example/config.xmlclasspath:file:http:

@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from "/app-config.xml" and
// "/test-config.xml" in the root of the classpath
@ContextConfiguration(locations={"/app-config.xml", "/test-config.xml"}) 
class MyTest {
    // class body...
}

将位置属性设置为 XML 文件列表。

@ContextConfiguration通过标准爪哇属性。因此，如果您不需要声明额外的属性中，可以省略属性名称的声明，并使用速记格式声明资源位置以下示例演示：locationsvalue@ContextConfigurationlocations

@ExtendWith(SpringExtension.class)
@ContextConfiguration({"/app-config.xml", "/test-config.xml"}) 
class MyTest {
    // class body...
}

指定 XML 文件而不使用属性。`location`

如果从注释中省略了 theand 属性，则 TestContext 框架会尝试检测默认值 XML 资源位置。具体来说，并根据测试的名称检测默认位置 .class。如果您的类已命名，则加载您的应用程序上下文来自。以下示例显示了如何执行此操作：locationsvalue@ContextConfigurationGenericXmlContextLoaderGenericXmlWebContextLoadercom.example.MyTestGenericXmlContextLoader"classpath:com/example/MyTest-context.xml"

@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from
// "classpath:com/example/MyTest-context.xml"
@ContextConfiguration 
class MyTest {
    // class body...
}

从默认位置加载配置。

使用时髦脚本进行上下文配置

若要使用使用Groovy Bean 定义 DSL 的 Groovy 脚本加载测试，可以注释您的测试类使用包含 Groovy 脚本的资源位置的数组配置 theorAttribute 。资源 Groovy脚本的查找语义与XML配置文件的查找语义相同。ApplicationContext@ContextConfigurationlocationsvalue

下面的示例演示如何指定 Groovy 配置文件：

@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from "/AppConfig.groovy" and
// "/TestConfig.groovy" in the root of the classpath
@ContextConfiguration({"/AppConfig.groovy", "/TestConfig.Groovy"}) 
class MyTest {
    // class body...
}

指定 Groovy 配置文件的位置。

如果从注释中省略这两个属性，TestContext 框架会尝试检测默认的 Groovy 脚本。具体来说，并根据测试类的名称检测默认位置。如果您的类已命名，则 Groovy 上下文加载器将从中加载应用程序上下文。以下示例演示如何使用默认值：locationsvalue@ContextConfigurationGenericGroovyXmlContextLoaderGenericGroovyXmlWebContextLoadercom.example.MyTest"classpath:com/example/MyTestContext.groovy"

@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from
// "classpath:com/example/MyTestContext.groovy"
@ContextConfiguration 
class MyTest {
    // class body...
}

使用组件类进行上下文配置

若要使用组件类加载测试（请参阅基于 Java 的容器配置），可以对测试进行批注类与和配置属性与数组包含对组件类的引用。以下示例演示如何执行此操作：ApplicationContext@ContextConfigurationclasses

@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from AppConfig and TestConfig
@ContextConfiguration(classes = {AppConfig.class, TestConfig.class}) 
class MyTest {
    // class body...
}

指定组件类。

如果从注释中省略属性， TestContext 框架尝试检测默认配置类的存在。具体来说，并检测测试类中满足以下要求的所有嵌套类配置类实现，如 @Configurationjavadoc 中指定。请注意，配置类的名称是任意的。此外，测试类可以如果需要，包含多个嵌套配置类。在下文中示例，类声明嵌套配置类命名自动用于加载测试的 .class：classes@ContextConfigurationAnnotationConfigContextLoaderAnnotationConfigWebContextLoaderstaticstaticOrderServiceTeststaticConfigApplicationContext

@SpringJUnitConfig 
// ApplicationContext will be loaded from the
// static nested Config class
class OrderServiceTest {

    @Configuration
    static class Config {

        // this bean will be injected into the OrderServiceTest class
        @Bean
        OrderService orderService() {
            OrderService orderService = new OrderServiceImpl();
            // set properties, etc.
            return orderService;
        }
    }

    @Autowired
    OrderService orderService;

    @Test
    void testOrderService() {
        // test the orderService
    }

}

	从嵌套类加载配置信息。`Config`

混合 XML、时髦脚本和组件类

有时可能需要混合 XML 配置文件、Groovy 脚本和组件类（通常为类）来配置测试。例如，如果在生产，您可能决定要使用类来配置用于测试的特定 Spring 管理组件，反之亦然。@ConfigurationApplicationContext@Configuration

此外，一些第三方框架（如Spring Boot）提供了一流的。支持从不同类型的资源加载同时（例如，XML 配置文件、Groovy 脚本和类）。从历史上看，Spring 框架不支持这一点标准部署。因此，大多数实现 Spring 框架在模块中仅支持一种资源类型对于每个测试上下文。但是，这并不意味着您不能同时使用两者。一一般规则的例外是 theand支持 XML 配置文件和 Groovy。同时编写脚本。此外，第三方框架可能会选择支持声明和标准测试支持在测试上下文框架中，您有以下选项。ApplicationContext@ConfigurationSmartContextLoaderspring-testGenericGroovyXmlContextLoaderGenericGroovyXmlWebContextLoaderlocationsclasses@ContextConfiguration

如果要使用资源位置（例如，XML 或 Groovy）和类来配置测试，则必须选择一个作为入口点，并且必须包括或导入另一个。例如，在XML或Groovy脚本中，您可以通过使用组件扫描或将它们定义为普通的Spring来包含类。 bean，而在类中，您可以使用导入 XML 配置文件或 Groovy 脚本。请注意，此行为在语义上是等效的有关如何在生产中配置应用程序：在生产配置中，您定义一组 XML 或 Groovy 资源位置或一组从中加载产品的类，但您仍然拥有 *包含或导入其他类型的配置。@Configuration@Configuration@Configuration@ImportResource@ConfigurationApplicationContext

使用上下文初始值设定项进行上下文配置

若要使用上下文初始值设定项为测试配置，注释您的测试类并使用包含对实现的类的引用的数组配置属性。然后，声明的上下文初始值设定项用于初始化为您的测试加载的内容。请注意，每个声明的初始值设定项支持的具体类型必须与的类型创建由 thein 使用（通常为 a）。此外，初始化器的调用顺序取决于它们是实现 Spring 的接口还是使用 Spring 的 sannotation 或标准注释进行注释。下面的示例演示如何使用初始值设定项：ApplicationContext@ContextConfigurationinitializersApplicationContextInitializerConfigurableApplicationContextConfigurableApplicationContextApplicationContextSmartContextLoaderGenericApplicationContextOrdered@Order@Priority

@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from TestConfig
// and initialized by TestAppCtxInitializer
@ContextConfiguration(
    classes = TestConfig.class,
    initializers = TestAppCtxInitializer.class) 
class MyTest {
    // class body...
}

使用配置类和初始值设定项指定配置。

您还可以省略 XML 配置文件、Groovy 脚本或组件类不完全，而是声明 only类，然后负责注册 bean 在上下文中 — 例如，通过以编程方式从 XML 加载 Bean 定义文件或配置类。以下示例演示如何执行此操作：@ContextConfigurationApplicationContextInitializer

@ExtendWith(SpringExtension.class)
// ApplicationContext will be initialized by EntireAppInitializer
// which presumably registers beans in the context
@ContextConfiguration(initializers = EntireAppInitializer.class) 
class MyTest {
    // class body...
}

仅使用初始值设定项指定配置。

上下文配置继承

@ContextConfiguration支持布尔和属性，这些属性表示资源位置还是组件类和上下文超类声明的初始值设定项应继承。两者的默认值旗帜是。这意味着测试类继承资源位置或组件类以及任何超类声明的上下文初始值设定项。具体而言，将追加测试类的资源位置或组件类到资源位置或超类声明的批注类的列表。同样，给定测试类的初始值设定项将添加到初始值设定项集中由测试超类定义。因此，子类可以选择扩展资源位置、组件类或上下文初始值设定项。inheritLocationsinheritInitializerstrue

如果 theorattribute inis 设置为，则资源位置或组件类和上下文初始值设定项分别用于测试类的影子和有效替换由超类定义的配置。inheritLocationsinheritInitializers@ContextConfigurationfalse

在下一个使用 XML 资源位置的示例中，foris 按该顺序加载自 and。因此，定义为 incan 的 bean 会覆盖（即替换）那些定义在。下面的示例演示一个类如何扩展另一个，同时使用自己的配置文件和超类的配置文件：ApplicationContextExtendedTestbase-config.xmlextended-config.xmlextended-config.xmlbase-config.xml

@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from "/base-config.xml"
// in the root of the classpath
@ContextConfiguration("/base-config.xml") 
class BaseTest {
    // class body...
}

// ApplicationContext will be loaded from "/base-config.xml" and
// "/extended-config.xml" in the root of the classpath
@ContextConfiguration("/extended-config.xml") 
class ExtendedTest extends BaseTest {
    // class body...
}

在超类中定义的配置文件。
子类中定义的配置文件。

类似地，在下一个使用组件类的示例中，从 theandclasses 加载的 foris 在次序。因此，定义为 incan 的 bean 覆盖（即替换）那些定义在。下面的示例演示一个类如何扩展另一个，并同时使用其自己的配置类和超类的配置类：ApplicationContextExtendedTestBaseConfigExtendedConfigExtendedConfigBaseConfig

// ApplicationContext will be loaded from BaseConfig
@SpringJUnitConfig(BaseConfig.class) 
class BaseTest {
    // class body...
}

// ApplicationContext will be loaded from BaseConfig and ExtendedConfig
@SpringJUnitConfig(ExtendedConfig.class) 
class ExtendedTest extends BaseTest {
    // class body...
}

在超类中定义的配置类。
在子类中定义的配置类。

在下一个使用上下文初始值设定项的示例中，foris 由 usingand 初始化。注意但是，调用初始值设定项的顺序取决于它们是否实现 Spring 的接口或用 Spring 的注释进行注释或标准注释。下面的示例演示一个类如何扩展另一个并使用其自己的初始值设定项和超类的初始值设定项：ApplicationContextExtendedTestBaseInitializerExtendedInitializerOrdered@Order@Priority

// ApplicationContext will be initialized by BaseInitializer
@SpringJUnitConfig(initializers = BaseInitializer.class) 
class BaseTest {
    // class body...
}

// ApplicationContext will be initialized by BaseInitializer
// and ExtendedInitializer
@SpringJUnitConfig(initializers = ExtendedInitializer.class) 
class ExtendedTest extends BaseTest {
    // class body...
}

超类中定义的初始值设定项。
子类中定义的初始值设定项。

使用环境配置文件进行上下文配置

Spring 框架对环境和配置文件的概念具有一流的支持（又名“Bean 定义配置文件”），并且可以配置集成测试以激活适用于各种测试场景的特定 Bean 定义配置文件。这是通过使用注释注释测试类并提供加载测试时应激活的配置文件。@ActiveProfilesApplicationContext

考虑两个包含 XML 配置和类的示例：@Configuration

<!-- app-config.xml -->
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jdbc="http://www.springframework.org/schema/jdbc"
    xmlns:jee="http://www.springframework.org/schema/jee"
    xsi:schemaLocation="...">

    <bean 
            class="com.bank.service.internal.DefaultTransferService">
        <constructor-arg ref="accountRepository"/>
        <constructor-arg ref="feePolicy"/>
    </bean>

    <bean 
            class="com.bank.repository.internal.JdbcAccountRepository">
        <constructor-arg ref="dataSource"/>
    </bean>

    <bean 
        class="com.bank.service.internal.ZeroFeePolicy"/>

    <beans profile="dev">
        <jdbc:embedded-database >
            <jdbc:script
                location="classpath:com/bank/config/sql/schema.sql"/>
            <jdbc:script
                location="classpath:com/bank/config/sql/test-data.sql"/>
        </jdbc:embedded-database>
    </beans>

    <beans profile="production">
        <jee:jndi-lookup  jndi-name="java:comp/env/jdbc/datasource"/>
    </beans>

    <beans profile="default">
        <jdbc:embedded-database >
            <jdbc:script
                location="classpath:com/bank/config/sql/schema.sql"/>
        </jdbc:embedded-database>
    </beans>

</beans>

@ExtendWith(SpringExtension.class)
// ApplicationContext will be loaded from "classpath:/app-config.xml"
@ContextConfiguration("/app-config.xml")
@ActiveProfiles("dev")
class TransferServiceTest {

    @Autowired
    TransferService transferService;

    @Test
    void testTransferService() {
        // test the transferService
    }
}

运行时，它从类路径根目录中的配置文件加载。如果你检查，你可以看到thebean依赖于abean。但是，未定义为* Bean。相反，被定义三次：在配置文件中，在配置文件中，并在个人资料中。TransferServiceTestApplicationContextapp-config.xmlapp-config.xmlaccountRepositorydataSourcedataSourcedataSourceproductiondevdefault

通过注释，我们指导春天测试上下文框架，以加载活动配置文件设置为。因此，将创建一个嵌入式数据库并填充测试数据，并且 Thebean与开发有关。这可能是我们在集成测试中想要的。TransferServiceTest@ActiveProfiles("dev")ApplicationContext{"dev"}accountRepositoryDataSource

有时将 bean 分配给配置文件很有用。默认内的 Bean 仅当未专门激活其他配置文件时，才会包含配置文件。您可以使用这用于定义要在应用程序默认状态中使用的“回退”bean。为例如，您可以显式提供数据源 forand配置文件，但是，当内存中数据源都不是活动状态时，将内存中数据源定义为默认值。defaultdevproduction

以下代码清单演示如何实现相同的配置和使用类而不是 XML 进行集成测试：@Configuration

@Configuration
@Profile("dev")
public class StandaloneDataConfig {

    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.HSQL)
            .addScript("classpath:com/bank/config/sql/schema.sql")
            .addScript("classpath:com/bank/config/sql/test-data.sql")
            .build();
    }
}

@Configuration
@Profile("production")
public class JndiDataConfig {

    @Bean(destroyMethod="")
    public DataSource dataSource() throws Exception {
        Context ctx = new InitialContext();
        return (DataSource) ctx.lookup("java:comp/env/jdbc/datasource");
    }
}

@Configuration
@Profile("default")
public class DefaultDataConfig {

    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.HSQL)
            .addScript("classpath:com/bank/config/sql/schema.sql")
            .build();
    }
}

@Configuration
public class TransferServiceConfig {

    @Autowired DataSource dataSource;

    @Bean
    public TransferService transferService() {
        return new DefaultTransferService(accountRepository(), feePolicy());
    }

    @Bean
    public AccountRepository accountRepository() {
        return new JdbcAccountRepository(dataSource);
    }

    @Bean
    public FeePolicy feePolicy() {
        return new ZeroFeePolicy();
    }
}

@SpringJUnitConfig({
        TransferServiceConfig.class,
        StandaloneDataConfig.class,
        JndiDataConfig.class,
        DefaultDataConfig.class})
@ActiveProfiles("dev")
class TransferServiceTest {

    @Autowired
    TransferService transferService;

    @Test
    void testTransferService() {
        // test the transferService
    }
}

在此变体中，我们将 XML 配置拆分为四个独立的类：@Configuration

TransferServiceConfig：通过使用依赖注入获取a。dataSource@Autowired
StandaloneDataConfig：为适用于开发人员测试。dataSource
JndiDataConfig：定义在生产中从 JNDI 检索的内容环境。dataSource
DefaultDataConfig：为默认嵌入式数据库定义 a，以防没有配置文件处于活动状态。dataSource

与基于 XML 的配置示例一样，我们仍然进行注释，但这次我们通过以下方式指定所有四个配置类使用注释。测试类本身的主体仍然存在完全不变。TransferServiceTest@ActiveProfiles("dev")@ContextConfiguration

通常情况下，跨多个测试类使用一组配置文件在给定项目中。因此，为了避免重复的注释声明，您可以在基类和子类上声明一次自动从基类继承配置。在以下示例，声明（以及其他注释）已移至抽象超类，：@ActiveProfiles@ActiveProfiles@ActiveProfiles@ActiveProfilesAbstractIntegrationTest

// "dev" profile inherited from superclass
class TransferServiceTest extends AbstractIntegrationTest {

    @Autowired
    TransferService transferService;

    @Test
    void testTransferService() {
        // test the transferService
    }
}

@ActiveProfiles还支持可用于禁用活动配置文件的继承，如以下示例所示：inheritProfiles

// "dev" profile overridden with "production"
@ActiveProfiles(profiles = "production", inheritProfiles = false)
class ProductionTransferServiceTest extends AbstractIntegrationTest {
    // test body
}

此外，有时需要解析用于测试的活动配置文件以编程方式而不是声明方式 — 例如，基于：

当前操作系统。
测试是否在持续集成生成服务器上运行。
某些环境变量的存在。
自定义类级批注的存在。
其他问题。

要以编程方式解析活动的 Bean 定义概要文件，您可以实现一个自定义并使用属性注册它。有关更多信息，请参阅相应的javadoc。下面的示例演示如何实现和注册自定义：ActiveProfilesResolverresolver@ActiveProfilesOperatingSystemActiveProfilesResolver

// "dev" profile overridden programmatically via a custom resolver
@ActiveProfiles(
        resolver = OperatingSystemActiveProfilesResolver.class,
        inheritProfiles = false)
class TransferServiceTest extends AbstractIntegrationTest {
    // test body
}

public class OperatingSystemActiveProfilesResolver implements ActiveProfilesResolver {

    @Override
    public String[] resolve(Class<?> testClass) {
        String profile = ...;
        // determine the value of profile based on the operating system
        return new String[] {profile};
    }
}

使用测试属性源进行上下文配置

Spring 框架对具有属性源的层次结构，您可以使用特定于测试的集成测试来配置属性源。与类上使用的注释相反，您可以在测试上声明注释类，用于声明测试属性文件或内联属性的资源位置。这些测试属性源被添加到集合中 for 加载用于带注释的集成测试。@PropertySource@Configuration@TestPropertySourcePropertySourcesEnvironmentApplicationContext

声明测试属性源

可以使用的理论属性配置测试属性文件。locationsvalue@TestPropertySource

支持传统和基于 XML 的属性文件格式，例如，OR。"classpath:/com/example/test.properties""file:///path/to/file.xml"

每条路径都被解释为一个弹簧。纯路径（例如）被视为相对于包的类路径资源在其中定义测试类。以斜杠开头的路径被视为绝对类路径资源（例如：）。一条路径引用 URL（例如，前缀为、、或的路径）是使用指定的资源协议加载。不允许使用资源位置通配符（例如）：每个位置的计算结果必须恰好为一个资源。Resource"test.properties""/org/example/test.xml"classpath:file:http:*/.properties.properties.xml

下面的示例使用测试属性文件：

@ContextConfiguration
@TestPropertySource("/test.properties") 
class MyIntegrationTests {
    // class body...
}

指定具有绝对路径的属性文件。

您可以使用的属性以键值对的形式配置内联属性，如下例所示。都键值对作为单个测试以最高优先级添加到封闭中。properties@TestPropertySourceEnvironmentPropertySource

键值对支持的语法与为中的条目定义的语法相同一个 Java 属性文件：

key=value
key:value
key value

下面的示例设置两个内联属性：

@ContextConfiguration
@TestPropertySource(properties = {"timezone = GMT", "port: 4242"}) 
class MyIntegrationTests {
    // class body...
}

使用键值语法的两种变体设置两个属性。

默认属性文件检测

将 ifis 声明为空注释（即，没有显式理论属性的值），尝试检测相对于声明批注的类的默认属性文件。例如如果带批注的测试类是，则相应的默认属性文件是。如果无法检测到默认值，则抛出 anis。@TestPropertySourcelocationspropertiescom.example.MyTestclasspath:com/example/MyTest.propertiesIllegalStateException

优先

测试属性的优先级高于操作系统中定义的优先级环境、Java 系统属性或应用程序添加的属性源通过使用或以编程方式以声明方式。因此，测试属性可以用于有选择地重写从系统和应用程序属性加载的属性来源。此外，内联属性的优先级高于加载的属性从资源位置。但是请注意，通过以下方式注册的属性@DynamicPropertySource 优先级高于加载方式的优先级。@PropertySource@TestPropertySource

在下一个示例中，定义的 andProperties 和任何属性将覆盖系统中定义的任何同名属性和应用程序属性源。此外，如果文件定义被内联覆盖的属性的条目使用属性声明的属性。以下示例演示如何在文件中和内联中指定属性：timezoneport"/test.properties""/test.properties"timezoneportproperties

@ContextConfiguration
@TestPropertySource(
    locations = "/test.properties",
    properties = {"timezone = GMT", "port: 4242"}
)
class MyIntegrationTests {
    // class body...
}

继承和重写测试属性源

@TestPropertySource支持布尔属性，这些属性指示属性文件和内联的资源位置超类声明的属性应该被继承。两个标志的默认值是。这意味着测试类继承位置和内联属性由任何超类声明。具体来说，位置和内联属性测试类追加到超类声明的位置和内联属性。因此，子类可以选择扩展位置和内联属性。注意以后出现的属性阴影（即覆盖）同名的属性出现较早。此外，上述优先规则适用于继承的同时测试属性源。inheritLocationsinheritPropertiestrue

如果理论属性 inis 设置为，分别是测试类的位置或内联属性影子并有效地替换超类定义的配置。inheritLocationsinheritProperties@TestPropertySourcefalse

在下一个示例中，仅使用文件作为测试属性源加载了 foris。相反，通过使用 theandfile 作为测试属性源位置来加载 foris。以下示例演示如何定义子类及其超类中的属性通过使用文件：ApplicationContextBaseTestbase.propertiesApplicationContextExtendedTestbase.propertiesextended.propertiesproperties

@TestPropertySource("base.properties")
@ContextConfiguration
class BaseTest {
    // ...
}

@TestPropertySource("extended.properties")
@ContextConfiguration
class ExtendedTest extends BaseTest {
    // ...
}

在下一个示例中，仅使用内联属性。相比之下，福里斯通过使用内联和属性加载。以下示例演示如何使用内联属性定义子类及其超类中的属性：ApplicationContextBaseTestkey1ApplicationContextExtendedTestkey1key2

@TestPropertySource(properties = "key1 = value1")
@ContextConfiguration
class BaseTest {
    // ...
}

@TestPropertySource(properties = "key2 = value2")
@ContextConfiguration
class ExtendedTest extends BaseTest {
    // ...
}

使用动态属性源进行上下文配置

从Spring Framework 5.2.5开始，TestContext框架通过注释提供了对动态属性的支持。此注释可用于需要将具有动态值的属性添加到集合中的集成测试，对于加载的集成测试。@DynamicPropertySourcePropertySourcesEnvironmentApplicationContext

与在类级别应用的@TestPropertySource注释相反，必须应用到接受单个参数的方法，该参数是用于将名称-值对添加到。值是动态的，通过 athis 仅在解析属性时调用。通常，方法引用用于提供值，如以下示例所示，该示例使用 Testcontainers 项目用于管理 Spring 之外的 Redis 容器。创建托管 Redis 容器的 IP 地址和端口可用于测试中的组件通过和属性。这些属性可以通过 Spring 的抽象访问或直接注入到 Spring 管理的组件中 - 例如，分别通过。@DynamicPropertySourcestaticDynamicPropertyRegistryEnvironmentSupplierApplicationContextApplicationContextredis.hostredis.portEnvironment@Value("${redis.host}")@Value("${redis.port}")

@SpringJUnitConfig(/* ... */)
@Testcontainers
class ExampleIntegrationTests {

    @Container
    static RedisContainer redis = new RedisContainer();

    @DynamicPropertySource
    static void redisProperties(DynamicPropertyRegistry registry) {
        registry.add("redis.host", redis::getHost);
        registry.add("redis.port", redis::getMappedPort);
    }

    // tests ...

}

优先

动态属性的优先级高于从中加载的属性，操作系统的环境、Java 系统属性或由添加的属性源应用程序以声明方式使用或以编程方式。因此动态属性可用于有选择地重写加载方式的属性、系统属性源和应用程序属性源。@TestPropertySource@PropertySource@TestPropertySource

正在加载一个`WebApplicationContext`

指示 TestContext 框架加载 a 而不是标准，您可以使用注释相应的测试类。WebApplicationContextApplicationContext@WebAppConfiguration

测试类的存在指示测试上下文框架（TCF）应该为您的（WAC）加载集成测试。在后台，TCF 确保创建并提供给测试的 WAC。默认情况下，您的基本资源路径设置为。这被解释为路径相对到 JVM 的根目录（通常是项目的路径）。如果您熟悉 Maven项目中Web应用程序的目录结构，您知道这是WAR根目录的默认位置。如果需要覆盖此默认值，您可以提供注释的备用路径（例如，）。如果您愿意从类路径而不是文件系统引用基资源路径，您可以使用春天的前缀。@WebAppConfigurationWebApplicationContextMockServletContextMockServletContextsrc/main/webappsrc/main/webapp@WebAppConfiguration@WebAppConfiguration("src/test/webapp")classpath:

请注意，Spring 对实现的测试支持是相当的支持标准实现。使用 a 进行测试时，您可以*声明 XML 配置文件、Groovy 脚本、或使用类。您也可以免费使用任何其他测试注释，例如,,,,等。WebApplicationContextApplicationContextWebApplicationContext@Configuration@ContextConfiguration@ActiveProfiles@TestExecutionListeners@Sql@Rollback

本节中的其余示例显示了加载 a.以下示例显示了测试上下文框架对约定重于配置的支持：WebApplicationContext

@ExtendWith(SpringExtension.class)

// defaults to "file:src/main/webapp"
@WebAppConfiguration

// detects "WacTests-context.xml" in the same package
// or static nested @Configuration classes
@ContextConfiguration
class WacTests {
    //...
}

如果在未指定资源的情况下批注测试类基路径，则资源路径实际上默认为。同样地如果您在没有指定资源、组件或上下文的情况下声明，Spring 会尝试检测是否存在使用约定（即在同一包中）进行配置作为类或静态嵌套类）。@WebAppConfigurationfile:src/main/webapp@ContextConfigurationlocationsclassesinitializersWacTests-context.xmlWacTests@Configuration

下面的示例演示如何使用以下内容显式声明资源基路径和 XML 资源位置：@WebAppConfiguration@ContextConfiguration

@ExtendWith(SpringExtension.class)

// file system resource
@WebAppConfiguration("webapp")

// classpath resource
@ContextConfiguration("/spring/test-servlet-config.xml")
class WacTests {
    //...
}

这里要注意的重要一点是具有这两个路径的不同语义附注。默认情况下，资源路径是基于文件系统的，而资源位置是基于类路径的。@WebAppConfiguration@ContextConfiguration

下面的示例演示我们可以覆盖两者的默认资源语义通过指定 Spring 资源前缀进行注释：

@ExtendWith(SpringExtension.class)

// classpath resource
@WebAppConfiguration("classpath:test-web-resources")

// file system resource
@ContextConfiguration("file:src/main/webapp/WEB-INF/servlet-config.xml")
class WacTests {
    //...
}

将此示例中的注释与上一示例中的注释进行对比。

使用 Web 模拟

为了提供全面的 Web 测试支持，TestContext 框架默认启用。当针对 a 进行测试时，此TestExecutionListener使用 Spring Web 的 before 设置默认的线程本地状态每个测试方法并创建一个、A 和 a基于配置的基本资源路径。还确保 THE AND 可以注入到测试实例中，并且，一旦测试完成，它将清理线程本地状态。ServletTestExecutionListenerWebApplicationContextRequestContextHolderMockHttpServletRequestMockHttpServletResponseServletWebRequest@WebAppConfigurationServletTestExecutionListenerMockHttpServletResponseServletWebRequest

加载测试后，您可能会发现需要与网络模拟进行交互 — 例如，设置测试装置或在调用 Web 组件后执行断言。以下示例显示哪个模拟可以自动连接到测试实例中。请注意，theand都是缓存在测试套件中，而其他模拟是按测试方法管理。WebApplicationContextWebApplicationContextMockServletContextServletTestExecutionListener

@SpringJUnitWebConfig
class WacTests {

    @Autowired
    WebApplicationContext wac; // cached

    @Autowired
    MockServletContext servletContext; // cached

    @Autowired
    MockHttpSession session;

    @Autowired
    MockHttpServletRequest request;

    @Autowired
    MockHttpServletResponse response;

    @Autowired
    ServletWebRequest webRequest;

    //...
}

上下文缓存

一旦 TestContext 框架加载了一个（或）对于测试，该上下文将被缓存并重用于声明同一测试套件中具有相同的唯一上下文配置。了解缓存方式工作，重要的是要理解“唯一”和“测试套件”的含义。ApplicationContextWebApplicationContext

Ancan 通过配置组合唯一标识用于加载它的参数。因此，独特的配置组合参数用于生成缓存上下文的键。测试上下文框架使用以下配置参数来构建上下文缓存键：ApplicationContext

locations（来自@ContextConfiguration)
classes（来自@ContextConfiguration)
contextInitializerClasses（来自@ContextConfiguration)
contextCustomizers（from） – 这包括Spring Boot的方法以及各种功能测试支持，如桑德。ContextCustomizerFactory@DynamicPropertySource@MockBean@SpyBean
contextLoader（来自@ContextConfiguration)
parent（来自@ContextHierarchy)
activeProfiles（来自@ActiveProfiles)
propertySourceLocations（来自@TestPropertySource)
propertySourceProperties（来自@TestPropertySource)
resourceBasePath（来自@WebAppConfiguration)

例如，ifspecifiesfor 的（或）属性，TestContext 框架加载相应的内容并将其存储在上下文缓存中在仅基于这些位置的密钥下。因此，if也定义了它的位置（显式或隐式通过继承）但不定义不同的、不同的活动配置文件、不同的上下文初始值设定项、不同的测试属性源或不同的父上下文，则 sameis 由两个测试类共享。这意味着加载应用程序的设置成本上下文仅发生一次（每个测试套件），后续测试执行很多更快。TestClassA{"app-config.xml", "test-config.xml"}locationsvalue@ContextConfigurationApplicationContextstaticTestClassB{"app-config.xml", "test-config.xml"}@WebAppConfigurationContextLoaderApplicationContext

上下文缓存的大小以默认的最大大小 32 为界。每当达到最大大小，使用最近最少使用（LRU）逐出策略来逐出和关闭过时的上下文。您可以从命令行或内部版本配置最大大小脚本，通过设置名为 JVM 系统属性。作为一个或者，您可以通过SpringProperties机制设置相同的属性。spring.test.context.cache.maxSize

由于在给定的测试套件中加载大量应用程序上下文可以导致套件运行不必要的长时间，这通常是有益的确切地知道已加载和缓存的上下文数。查看的统计信息对于基础上下文缓存，可以将日志记录类别的日志级别设置为。org.springframework.test.context.cacheDEBUG

在极少数情况下，测试会损坏应用程序上下文并需要重新加载（例如，通过修改 Bean 定义或应用程序对象的状态），您可以可以注释您的测试类或测试方法（请参阅春季测试中的讨论注释）。这指示 Spring 从缓存中删除上下文并重建运行下一个需要相同应用程序的测试之前的应用程序上下文上下文。请注意，对注释的支持由 theand 提供，默认情况下处于启用状态。@DirtiesContext@DirtiesContext@DirtiesContextDirtiesContextBeforeModesTestExecutionListenerDirtiesContextTestExecutionListener

上下文层次结构

在编写依赖于加载的 Spring 的集成测试时，它是通常足以针对单个上下文进行测试。但是，有时它是对针对实例层次结构进行测试是有益的，甚至是必要的。例如，如果您正在开发Spring MVC Web应用程序，则通常有根被春天的沙子被春天的孩子装了。这导致父子上下文层次结构，其*享组件和基础结构配置在根上下文中声明，并由特定于 Web 的在子上下文中使用组件。另一个用例可以在Spring Batch应用程序中找到，您经常在其中具有为共享批处理基础结构提供配置的父上下文和用于配置特定批处理作业的子上下文。ApplicationContextApplicationContextWebApplicationContextContextLoaderListenerWebApplicationContextDispatcherServlet

您可以通过声明上下文来编写使用上下文层次结构的集成测试在单个测试类上使用注释进行配置或在测试类层次结构中。如果在多个类上声明了上下文层次结构在测试类层次结构中，还可以合并或覆盖上下文配置对于上下文层次结构中的特定命名级别。合并的配置时层次结构中的给定级别，配置资源类型（即 XML 配置文件或组件类）必须一致。否则，完全可以接受在使用不同资源类型配置的上下文层次结构中具有不同的级别。@ContextHierarchy

本节中其余基于 JUnit Jupiter 的示例显示了常见配置需要使用上下文层次结构的集成测试方案。

具有上下文层次结构的单个测试类

ControllerIntegrationTests表示 Spring MVC Web 应用程序通过声明由两个级别组成的上下文层次结构，一个用于根（通过使用类加载），一个用于调度程序 servlet（通过使用类加载）。自动连接到测试实例的是子上下文（即层次结构中的最低上下文）。以下清单显示了此配置方案：WebApplicationContextTestAppConfig@ConfigurationWebApplicationContextWebConfig@ConfigurationWebApplicationContext

@ExtendWith(SpringExtension.class)
@WebAppConfiguration
@ContextHierarchy({
    @ContextConfiguration(classes = TestAppConfig.class),
    @ContextConfiguration(classes = WebConfig.class)
})
class ControllerIntegrationTests {

    @Autowired
    WebApplicationContext wac;

    // ...
}

具有隐式父上下文的类层次结构

此示例中的测试类定义测试类中的上下文层次结构 hierarchy.声明根在 Spring 驱动的 Web 应用程序中的配置。但是请注意，这并没有声明。因此，子类可以选择参与上下文层次结构或遵循标准语义和扩展定义上下文层次结构用。结果是加载了三个应用程序上下文（一个对于的每个声明），以及加载的应用程序上下文基于配置为每个为具体子类加载的上下文。以下清单显示了这一点配置方案：AbstractWebTestsWebApplicationContextAbstractWebTests@ContextHierarchyAbstractWebTests@ContextConfigurationSoapWebServiceTestsRestWebServiceTestsAbstractWebTests@ContextHierarchy@ContextConfigurationAbstractWebTests

@ExtendWith(SpringExtension.class)
@WebAppConfiguration
@ContextConfiguration("file:src/main/webapp/WEB-INF/applicationContext.xml")
public abstract class AbstractWebTests {}

@ContextHierarchy(@ContextConfiguration("/spring/soap-ws-config.xml"))
public class SoapWebServiceTests extends AbstractWebTests {}

@ContextHierarchy(@ContextConfiguration("/spring/rest-ws-config.xml"))
public class RestWebServiceTests extends AbstractWebTests {}

具有合并上下文层次结构配置的类层次结构

此示例中的类显示了如何使用命名层次结构级别来合并上下文层次结构中特定级别的配置。定义两个级别在层次结构中，和.扩展和指示 Spring TestContext 框架通过确保属性中声明的名称同时存在两者来合并层次结构级别的上下文配置。结果是三个应用程序上下文已加载：一个用于、一个用于和一个用于。与前面的示例一样，加载自的应用程序上下文设置为父上下文加载自的上下文。以下清单显示了此配置方案：BaseTestsparentchildExtendedTestsBaseTestschildname@ContextConfigurationchild/app-config.xml/user-config.xml{"/user-config.xml", "/order-config.xml"}/app-config.xml/user-config.xml{"/user-config.xml", "/order-config.xml"}

@ExtendWith(SpringExtension.class)
@ContextHierarchy({
    @ContextConfiguration(name = "parent", locations = "/app-config.xml"),
    @ContextConfiguration(name = "child", locations = "/user-config.xml")
})
class BaseTests {}

@ContextHierarchy(
    @ContextConfiguration(name = "child", locations = "/order-config.xml")
)
class ExtendedTests extends BaseTests {}

具有重写上下文层次结构配置的类层次结构

与前面的示例相比，此示例演示了如何重写通过设置 Flag 为在上下文层次结构中配置给定命名级别。因此，应用程序上下文 foris 仅从和加载将其父级设置为从中加载的上下文。以下列表显示了以下配置方案：inheritLocations@ContextConfigurationfalseExtendedTests/test-user-config.xml/app-config.xml

@ExtendWith(SpringExtension.class)
@ContextHierarchy({
    @ContextConfiguration(name = "parent", locations = "/app-config.xml"),
    @ContextConfiguration(name = "child", locations = "/user-config.xml")
})
class BaseTests {}

@ContextHierarchy(
    @ContextConfiguration(
        name = "child",
        locations = "/test-user-config.xml",
        inheritLocations = false
))
class ExtendedTests extends BaseTests {}

Spring 对集成测试的支持和单元的最佳实践测试

1. 弹簧测试简介

2. 单元测试

2.1. 模拟对象

2.1.1. 环境

2.1.2. JNDI

2.1.3. servlet API

2.1.4. 弹簧网反应式

2.2. 单元测试支持类

2.2.1. 一般测试实用程序

2.2.2. 弹簧 MVC 测试实用程序

3. 集成测试

3.1. 概述

3.2. 集成测试的目标

3.2.1. 上下文管理和缓存

3.2.2. 测试治具的依赖注入

3.2.3. 事务管理

3.2.4. 集成测试的支持类

3.3. JDBC 测试支持

3.4. 注释

3.4.1. 弹簧测试注释

​​@BootstrapWith​​

​​@ContextConfiguration​​

​​@WebAppConfiguration​​

​​@ContextHierarchy​​

​​@ActiveProfiles​​

​​@TestPropertySource​​

​​@DynamicPropertySource​​

​​@DirtiesContext​​

​​@TestExecutionListeners​​

​​@RecordApplicationEvents​​

​​@Commit​​

​​@Rollback​​

​​@BeforeTransaction​​

​​@AfterTransaction​​

​​@Sql​​

​​@SqlConfig​​

​​@SqlMergeMode​​

​​@SqlGroup​​

3.4.2. 标准注释支持

3.4.3. 春季 JUnit 4 测试注释

​​@IfProfileValue​​

​​@ProfileValueSourceConfiguration​​

​​@Timed​​

​​@Repeat​​

3.4.4. 春季 JUnit 木星测试注释

​​@SpringJUnitConfig​​

​​@SpringJUnitWebConfig​​

​​@TestConstructor​​

​​@NestedTestConfiguration​​

​​@EnabledIf​​

​​@DisabledIf​​

3.4.5. 测试的元注释支持

3.5. 弹簧测试上下文框架

3.5.1. 关键抽象

​​TestContext​​

​​TestContextManager​​

​​TestExecutionListener​​

上下文加载器

3.5.2. 引导测试上下文框架

3.5.3.配置​​TestExecutionListener​​

注册实现​​TestExecutionListener​​

自动发现默认实现​​TestExecutionListener​​

排序实现​​TestExecutionListener​​

合并实现​​TestExecutionListener​​

3.5.4. 应用程序事件

3.5.5. 测试执行事件

异常处理

异步侦听器

3.5.6. 上下文管理

使用 XML 资源进行上下文配置

使用时髦脚本进行上下文配置

使用组件类进行上下文配置

混合 XML、时髦脚本和组件类

使用上下文初始值设定项进行上下文配置

上下文配置继承

使用环境配置文件进行上下文配置

使用测试属性源进行上下文配置

声明测试属性源

默认属性文件检测

`@BootstrapWith`

`@ContextConfiguration`

`@WebAppConfiguration`

`@ContextHierarchy`

`@ActiveProfiles`

`@TestPropertySource`

`@DynamicPropertySource`

`@DirtiesContext`

`@TestExecutionListeners`

`@RecordApplicationEvents`

`@Commit`

`@Rollback`

`@BeforeTransaction`

`@AfterTransaction`

`@Sql`

`@SqlConfig`

`@SqlMergeMode`

`@SqlGroup`

`@IfProfileValue`

`@ProfileValueSourceConfiguration`

`@Timed`

`@Repeat`

`@SpringJUnitConfig`

`@SpringJUnitWebConfig`

`@TestConstructor`

`@NestedTestConfiguration`

`@EnabledIf`

`@DisabledIf`

`TestContext`

`TestContextManager`

`TestExecutionListener`

3.5.3.配置`TestExecutionListener`

注册实现`TestExecutionListener`

自动发现默认实现`TestExecutionListener`

排序实现`TestExecutionListener`

合并实现`TestExecutionListener`

正在加载一个`WebApplicationContext`