Testing

Spring Boot 提供了许多实用工具和注释,以帮助测试你的应用程序.测试支持由两个模块提供: spring-boot-test 包含核心项目,而 spring-boot-test-autoconfigure 支持自动配置测试. 大多数开发人员使用 spring-boot-starter-test “Starter”,它导入 Spring Boot 的两项测试模块以及 JUnit Jupiter、AssertJ、Hamcrest 以及许多其他有用的库.

如果你具有使用 JUnit 4 的测试,则可以使用 JUnit 5 的 vintage 引擎来运行它们.若要使用 vintage 引擎,请添加对 junit-vintage-engine 的依赖,如下例所示:

<dependency>
	<groupId>org.junit.vintage</groupId>
	<artifactId>junit-vintage-engine</artifactId>
	<scope>test</scope>
	<exclusions>
		<exclusion>
			<groupId>org.hamcrest</groupId>
			<artifactId>hamcrest-core</artifactId>
		</exclusion>
	</exclusions>
</dependency>

hamcrest-core`被排除在外，优先使用 `org.hamcrest:hamcrest，后者是 `spring-boot-starter-test`的一部分。

Test Scope Dependencies

spring-boot-starter-test “Starter”（在 test `scope`中）包含以下提供的库：

  • JUnit 5：用于测试 Java 应用程序的事实标准。

  • {url-spring-framework-docs}/testing/integration.html[Spring Test] 和 Spring Boot Test：Spring Boot 应用程序的实用工具和集成测试支持。

  • AssertJ：一个流畅的断言库。

  • Hamcrest：一个匹配器对象库（也称为约束或谓词）。

  • Mockito：一个 Java 模拟框架。

  • JSONassert：一个用于 JSON 的断言库。

  • JsonPath: XPath for JSON.

  • Awaitility：一个用于测试异步系统的库。

我们通常会发现这些常见的库在写测试时很有用。如果这些库不适合您的需要，则可以添加您自己的额外的测试依赖项。

Testing Spring Applications

依赖注入的一大优点在于它应该让您的代码更容易进行单元测试。您可以使用 `new`运算符实例化对象，而无需 Spring 参与。您还可以使用 _mock objects_代替实际依赖项。

通常，您需要超越单元测试，并开始集成测试（使用 Spring ApplicationContext）。能够在不需要部署您的应用程序或不需要连接到其他基础设施的情况下执行集成测试非常有用。

Spring 框架包含一个专门用于此类集成测试的测试模块。您可以直接对 org.springframework:spring-test`声明一个依赖项，或使用 `spring-boot-starter-test "`Starter`"以传递方式引入它。

如果您之前没有使用过 `spring-test`模块，您应该首先阅读 Spring 框架参考文档中{url-spring-framework-docs}/testing.html[相关部分]。

Testing Spring Boot Applications

Spring Boot 应用程序是一个 Spring ApplicationContext，因此除了针对普通 Spring 上下文通常要做的工作之外，测试它不需要做任何特别的事情。

Spring Boot 的外部属性、日志记录和其他功能只有在您使用 `SpringApplication`创建上下文时才会默认安装到上下文中。

Spring Boot 提供一个 @SpringBootTest`注释，当您需要 Spring Boot 功能时，它可以用作标准 `spring-test @ContextConfiguration`注释的替代项。注释通过 creating the `ApplicationContext used in your tests through SpringApplication起作用。除了 `@SpringBootTest`之外，还提供了一些其他注释以 testing more specific slices应用程序。

如果您使用的是 JUnit 4，请不要忘记还将 @RunWith(SpringRunner.class)`添加到您的测试中，否则将忽略注释。如果您使用的是 JUnit 5，则无需添加等效的 `@ExtendWith(SpringExtension.class)，因为 `@SpringBootTest`和其他 `@…​Test`注释已使用其做了注释。

默认情况下，`@SpringBootTest`不会启动服务器。您可以使用 `@SpringBootTest`的 `webEnvironment`属性以进一步细化测试的运行方式：

  • MOCK （默认）：加载 Web 应用程序上下文并提供一个模拟的 Web 环境。使用此注释时不会启动嵌入式服务器。如果类路径上没有 Web 环境，则此模式会透明地回退为创建常规的、非 Web ApplicationContext。它可以与 @AutoConfigureMockMvc or @AutoConfigureWebTestClient结合使用，以对您的 Web 应用程序进行基于模拟的测试。

  • RANDOM_PORT：加载 Web 应用程序上下文并提供一个真正的 Web 环境。启动嵌入式服务器并侦听一个随机端口。

  • DEFINED_PORT：加载 Web 应用程序上下文并提供一个真正的 Web 环境。启动嵌入式服务器并侦听一个已定义的端口（来自您的 application.properties）或 `8080`的默认端口。

  • NONE：使用 `SpringApplication`加载 Web 应用程序上下文，但不提供 _any_Web 环境（模拟或其他）。

如果您的测试是 @Transactional，它默认会在每个测试方法的末尾回滚事务。但是，由于将此机制与 `RANDOM_PORT`或 `DEFINED_PORT`结合使用隐式地提供了一个真正的 Servlet 环境，因此 HTTP 客户端和服务器在单独的线程中运行，从而在单独的事务中运行。在这种情况下，在服务器上发起的任何事务都不会回滚。

`@SpringBootTest`与 `webEnvironment = WebEnvironment.RANDOM_PORT`还将在一个单独的随机端口上启动管理服务器，如果您的应用程序针对管理服务器使用某个不同的端口。

Detecting Web Application Type

如果提供了 Spring MVC，则会配置基于常规 MVC 的应用程序上下文。如果您只有 Spring WebFlux，则我们会检测到这一点并改为配置基于 WebFlux 的应用程序上下文。

如果两个都存在，则 Spring MVC 优先。如果您希望在此场景中测试响应式 Web 应用程序，则必须设置 configprop:spring.main.web-application-type[] 属性：

Detecting Test Configuration

如果您熟悉 Spring 测试框架，则可能习惯使用 `@ContextConfiguration(classes=…​)`以指定要加载哪个 Spring 应用程序上下文。此外，您可能经常在测试中使用嵌套的 `@Configuration`类。

在测试 Spring Boot 应用程序时，通常不需要这样做。Spring Boot 的 `@*Test`注释会在您没有明确定义一个注释时自动搜索您的主配置。

搜索算法从包含测试的包开始，一直往上查找，直到找到使用 `@SpringBootApplication`或 `@SpringBootConfiguration`进行注释的类。只要您以合理的方式进行 structured your code，通常能够找到您的主配置。

如果您使用了 test annotation to test a more specific slice of your application，则应该避免向 main method’s application class上特定区域添加配置设置。 `@SpringBootApplication`的底层组件扫描配置定义了排除过滤器，这些过滤器用于确保分片工作按预期进行。如果您在 `@SpringBootApplication`注释类上使用明确的 `@ComponentScan`指令，请注意这些过滤器将被禁用。如果您正在使用分片，则应重新定义它们。

如果您想要自定义主配置，可以使用一个嵌套 `@TestConfiguration`类。与将用作应用程序主配置的嵌套 `@Configuration`类不同，嵌套的 `@TestConfiguration`类是作为应用程序主配置的补充使用的。

Spring 的测试框架会缓存测试之间的应用程序上下文。因此，只要您的测试共享相同的配置（无论如何发现的），加载上下文的耗时过程只发生一次。

Using the Test Configuration Main Method

通常，@SpringBootTest`发现的测试配置将是您的主 `@SpringBootApplication。在大多数结构良好的应用程序中，此配置类还将包含用于启动应用程序的 `main`方法。

例如,以下代码模式对于典型的 Spring Boot 应用程序来说非常常见:

在上述示例中,main 方法除了委托给 SpringApplication.run 之外,不会执行任何其他操作.但是,在调用 SpringApplication.run 之前,可以通过更复杂的 main 方法来应用自定义设置.

例如,以下是一个更改横幅模式并设置其他配置文件的应用程序:

由于 main 方法中的自定义会影响由此产生的 ApplicationContext，所以您可能还想使用 main 方法来创建测试中使用的 ApplicationContext。默认情况下，@SpringBootTest 不会调用您的 main 方法，而是直接使用类本身来创建 ApplicationContext

如果您想更改此行为，可以将 @SpringBootTest 的 useMainMethod 属性更改为 UseMainMethod.ALWAYS 或 UseMainMethod.WHEN_AVAILABLE。如果将其设置为 ALWAYS，并且无法找到 main 方法，则测试将失败。如果将其设置为 WHEN_AVAILABLE，如果存在 main 方法，它将被使用；否则，将使用标准加载机制。

例如，以下测试将调用 MyApplication 的 main 方法以创建 ApplicationContext。如果主方法设置另外的配置文件，则当 ApplicationContext 启动时它们将处于活动状态。

Excluding Test Configuration

如果你的应用程序使用组件扫描（例如，如果你使用 @SpringBootApplication 或 @ComponentScan），你可能会发现自己只为特定测试创建的顶级配置类意外地被到处选取。

正如我们have seen earlier，@TestConfiguration 可以用于测试的内部类以自定义主配置。@TestConfiguration 也可以用于顶级类。这样表示该类不应通过扫描选取。然后，你可以在需要的地方显式导入该类，如下面的示例中所示：

如果你直接使用 @ComponentScan（即，不通过 @SpringBootApplication），则需要向其注册 TypeExcludeFilter。有关详细信息，请参阅 the Javadoc。

已导入的 @TestConfiguration 的处理时间比内部类 @TestConfiguration 早，已导入的 @TestConfiguration 的处理时间将比通过组件扫描找到的任何配置早。一般来说，这种排序差异没有明显的影响，但如果你依赖于 Bean 覆盖，则需要意识到这一点。

Using Application Arguments

如果您的应用程序期望 arguments，您可以使用 args 属性让 @SpringBootTest 注入它们。

Testing With a Mock Environment

默认情况下，@SpringBootTest 不会启动服务器，而是为测试 Web 端点设置模拟环境。

使用 Spring MVC，我们可以使用 {url-spring-framework-docs}/testing/spring-mvc-test-framework.html[MockMvc] 或 WebTestClient 查询我们的 Web 端点，如下例所示：

如果您只想关注 Web 层而不想启动一个完整的 ApplicationContext，请考虑 using @WebMvcTest instead。

使用 Spring WebFlux 端点，您可以使用 {url-spring-framework-docs}/testing/webtestclient.html[WebTestClient]，如下例所示：

包括代码：MyMockWebTestClientTests[]

在模拟环境里进行测试通常比使用完整的 Servlet 容器运行测试更快。但是，由于模拟发生在 Spring MVC 层，因此依赖于较低级别 Servlet 容器行为的代码无法使用 MockMvc 直接进行测试。 例如，Spring Boot 的错误处理基于 servlet 容器提供的 “error page” 支持。这意味着，虽然可以测试 MVC 层按预期抛出和处理异常，但无法直接测试是否渲染了特定的 custom error page。如果需要测试这些低层级问题，可以按照下一部分中所述启动一个完全运行的服务器。

Testing With a Running Server

如果需要启动一个完全运行的服务器，建议使用随机端口。如果使用 @SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT)，那么在每次运行测试时都会随机选择一个可用端口。

可以 inject the actual port used 到测试中，以使用 @LocalServerPort 批注。为了方便，需要对已启动的服务器进行 REST 调用的测试还可以 @Autowire 一个 {url-spring-framework-docs}/testing/webtestclient.html[WebTestClient]，该注解解析到正在运行的服务器的相对链接，并提供了一个专门的 API 用于验证响应，如下例所示：

在测试中使用 inject the actual port used 代码：MyRandomPortWebTestClientTests[]

WebTestClient 也可与 mock environment 结合使用，省去了使用运行服务器的必要性，方法是通过 @AutoConfigureWebTestClient 为测试类添加批注。

此设置需要 spring-webflux 位于类路径上。如果无法或不愿添加 WebFlux，Spring Boot 还提供了一个 TestRestTemplate 工具：

在测试中使用 TestRestTemplate 代码：MyRandomPortTestRestTemplateTests[]

Customizing WebTestClient

若要自定义 WebTestClient bean，请配置 WebTestClientBuilderCustomizer bean。此类任何 bean 都使用用于创建 WebTestClient 的 WebTestClient.Builder 进行调用。

Using JMX

由于测试上下文框架会缓存上下文，所以 JMX 默认被禁用，以防止相同组件注册在同一域上。如果此类测试需要访问 MBeanServer，请考虑也将其标记为脏：

在测试中使用 MBeanServer 代码：MyJmxTests[]

Using Observations

如果为 a sliced test 添加 @AutoConfigureObservability 批注，它将自动配置一个 ObservationRegistry。

Using Metrics

无论类路径是什么，使用 @SpringBootTest 时，仪表注册表（除了内存后备）都不会自动配置。

如果需要在集成测试中将指标导出到不同后端，请对其添加 @AutoConfigureObservability 批注。

如果为 a sliced test 添加 @AutoConfigureObservability 批注，它会自动配置一个内存 MeterRegistry。在分块测试中使用 @AutoConfigureObservability 批注进行数据导出不受支持。

Using Tracing

无论您的类路径如何，在使用 `@SpringBootTest`时，报告数据的跟踪组件均不会自动配置。

如果您需要那些组件作为集成测试的一部分，请使用 @AutoConfigureObservability 注释该测试。

如果您已创建了自定义报告组件（例如自定义 SpanExporter 或 SpanHandler），并且您不希望它们在测试中处于活动状态，则可以使用 @ConditionalOnEnabledTracing 注释禁用它们。

如果您使用 @AutoConfigureObservability 注释 a sliced test ，它将自动配置无操作 Tracer 。使用 @AutoConfigureObservability 注释，在切片测试中不支持数据导出。

Mocking and Spying Beans

在运行测试时，有时需要模拟应用程序上下文中特定组件。例如，在开发过程中可能无法使用某个远程服务的模式。当您想要模拟在真实的环境中可能难以触发的故障时，模拟也可能非常有用。

Spring Boot 包含 @MockBean 注释，该注释可用于为 ApplicationContext 内的 Bean 定义一个 Mockito 模拟。可以使用此注释添加新 Bean 或替换现有的单一 Bean 定义。此注释可直接用于测试类、测试中的字段或 @Configuration 类和字段。当用在字段上时，也会注入创建的模拟实例。模拟 Bean 会在每次测试方法后自动重置。

如果您的测试使用 Spring Boot 的任何测试注释（例如 @SpringBootTest），则此功能将自动启用。要将此功能与不同排列一起使用，必须明确添加侦听器，如下例所示： include-code::listener/MyTests[]

以下示例使用模拟实现替换现有 RemoteService Bean：

@MockBean 不能用于模拟在应用程序上下文刷新期间执行的 Bean 的行为。在执行测试时，应用程序上下文刷新已完成，并且配置模拟行为已为时已晚。我们建议在这种情况下使用 @Bean 方法创建和配置模拟。

此外，您还可以使用 @SpyBean 包装任何现有 Bean 使用 Mockito spy 。有关详细信息，请参阅 Javadoc 。

虽然 Spring 的测试框架在测试之间缓存应用程序上下文并为共享相同配置的测试重新使用一个上下文，但使用 @MockBean 或 @SpyBean 会影响缓存密钥，这很可能会增加上下文的数量。

如果您正在使用 @SpyBean 使用 @Cacheable 方法来监视 Bean，而该方法按名称引用参数，则必须使用 -parameters 编译您的应用程序。这可确保一旦 Bean 被监视，参数名称就可以供缓存基础设施使用。

当您使用 @SpyBean 监视由 Spring 代理的 Bean 时，在某些情况下您可能需要移除 Spring 的代理，例如使用 given 或 when 设置预期时。使用 AopTestUtils.getTargetObject(yourProxiedSpy) 进行移除。

Auto-configured Tests

Spring Boot 的自动配置系统适用于应用程序，但有时对于测试来说可能会有点过分。它通常有助于仅加载测试应用程序的 “slice” 所需的配置部分。例如，您可能希望测试 Spring MVC 控制器是否正确映射了 URL，并且您不希望在这些测试中涉及数据库调用，或者您可能希望测试 JPA 实体，并且您在这些测试运行时不关心 Web 层。

spring-boot-test-autoconfigure 模块包含许多注释，可用于自动配置此类 “slices” 。它们每个的工作方式类似，提供加载 ApplicationContext 和一个或多个可用于自定义自动配置设置的 @AutoConfigure…​ 注释的 @…​Test 注释。

每个切片将组件扫描限制为适当的组件，并加载非常有限的一组自动配置类。如果您需要排除其中之一，大多数 @…​Test 注释提供一个 excludeAutoConfiguration 属性。或者，您可以使用 @ImportAutoConfiguration#exclude 。

在一个测试中使用多个 “slices” 时，不支持使用多个 @…​Test 注解。如果您需要多个 “slices”，请选取一个 @…​Test 注解，并手动包含其他 “slices” 的 @AutoConfigure…​ 注解。

还可以将 @AutoConfigure…​ 注解与标准 @SpringBootTest 注解一起使用。如果您对 “slicing” 应用程序不感兴趣，但希望得到部分自动配置的测试 bean，则可以使用此组合。

Auto-configured JSON Tests

使用 @JsonTest 注解测试对象 JSON 序列化和反序列化的工作是否符合预期。@JsonTest 自动配置可用的受支持 JSON 映射器，映射器可能是以下某个库：

  • Jackson ObjectMapper、任何 @JsonComponent bean 和任何 Jackson Module

  • Gson

  • Jsonb

由 @JsonTest 启用的自动配置列表可以 found in the appendix。

如果您需要配置自动配置的元素，可以使用 @AutoConfigureJsonTesters 注解。

Spring Boot 包含基于 AssertJ 的帮助器，可与 JSONAssert 和 JsonPath 库配合使用，以检查 JSON 是否符合预期。JacksonTester、GsonTester、JsonbTester 和 BasicJsonTester 类分别可用于 Jackson、Gson、Jsonb 和字符串。在使用 @JsonTest 时，测试类上的任何帮助器字段均可 @Autowired。以下示例显示 Jackson 的测试类：

JSON 帮助器类还可以在标准单元测试中直接使用。若要执行此操作，请在 @Before 方法中调用帮助器的 initFields 方法（如果您不使用 @JsonTest）。

如果您使用 Spring Boot 基于 AssertJ 的帮助器来断言给定 JSON 路径处的数值，则可能无法根据类型使用 isEqualTo。相反，您可以使用 AssertJ 的 satisfies 来断言该值符合给定的条件。例如，以下示例断言实际数字是一个浮点值，接近 0.15，偏移量在 0.01 之内。

Auto-configured Spring MVC Tests

要测试 Spring MVC 控制器是否符合预期，请使用 @WebMvcTest 注解。@WebMvcTest 自动配置 Spring MVC 基础架构，并使扫描的 bean 仅限于 @Controller、@ControllerAdvice、@JsonComponent、Converter、GenericConverter、Filter、HandlerInterceptor、WebMvcConfigurer、WebMvcRegistrations 和 HandlerMethodArgumentResolver。使用 @WebMvcTest 注解时，不会扫描常规 @Component 和 @ConfigurationProperties bean。可以使用 @EnableConfigurationProperties 来包含 @ConfigurationProperties bean。

可以 found in the appendix 启用 @WebMvcTest 的自动配置设置列表。

如果您需要注册其他组件，如 Jackson Module，则可以在测试中使用 @Import 来导入附加配置类。

通常，@WebMvcTest 被限制到单个控制器，并与 @MockBean 结合使用，以便为必需的协作者提供模拟实现。

@WebMvcTest 还自动配置 MockMvc。模拟 MVC 提供了一种快速测试 MVC 控制器的方法，而无需启动一个完整的 HTTP 服务器。

您还可以在非 @WebMvcTest （例如 @SpringBootTest）中使用 @AutoConfigureMockMvc 对 MockMvc 进行自动配置。以下示例使用 MockMvc：

如果您需要配置自动配置的元素（例如，应应用哪些 servlet 过滤器），则可以在 @AutoConfigureMockMvc 注解中使用属性。

如果您使用 HtmlUnit 和 Selenium，自动配置还提供了一个 HtmlUnit WebClient bean 和/或一个 Selenium WebDriver bean。以下示例使用 HtmlUnit：

包含代码：MyHtmlUnitTests[]

默认情况下，Spring Boot 将 WebDriver bean 放入一个特殊的 “scope” 中，以确保在每个测试后驱动程序退出，并注入一个新实例。如果您不希望出现此行为，可以将 @Scope("singleton") 添加到 WebDriver @Bean 定义中。

Spring Boot 创建的 webDriver 作用域将替换同名的任何用户定义作用域。如果您定义自己的 webDriver 作用域，可能会发现当使用 @WebMvcTest 时它停止工作。

如果类路径上有 Spring Security，@WebMvcTest 也将扫描 WebSecurityConfigurer bean。您可以使用 Spring Security 的测试支持，而不用为此类测试完全禁用安全。有关如何使用 Spring Security 的 MockMvc 支持的更多详细内容，请参阅此 Testing With Spring Security 指南部分。

有时编写 Spring MVC 测试还不够；Spring Boot 可以帮助您运行 full end-to-end tests with an actual server。

Auto-configured Spring WebFlux Tests

要测试 {url-spring-framework-docs}/web-reactive.html[Spring WebFlux] 控制器是否按预期工作，可以使用 @WebFluxTest 注解。@WebFluxTest 自动配置 Spring WebFlux 基础设施，并将扫描的 bean 限制为 @Controller、@ControllerAdvice、@JsonComponent、Converter、GenericConverter、WebFilter 和 WebFluxConfigurer。使用 @WebFluxTest 注解时，不会扫描常规 @Component 和 @ConfigurationProperties bean。可以用 @EnableConfigurationProperties 包括 @ConfigurationProperties bean。

可以通过 found in the appendix获取 @WebFluxTest 启用的自动配置列表。

如果您需要注册额外的组件，如 Jackson Module，可以在测试中使用 @Import 导入额外的配置类。

通常，@WebFluxTest 局限于单个控制器，并与 @MockBean 注解结合使用，为所需的协作者提供模拟实现。

@WebFluxTest 还自动配置了 {url-spring-framework-docs}/testing/webtestclient.html[WebTestClient]，它提供了一种强大的方式来快速测试 WebFlux 控制器，而无需启动完整的 HTTP 服务器。

您还可以在非 @WebFluxTest （例如 @SpringBootTest）中通过使用 @AutoConfigureWebTestClient 对其进行注释来自动配置 WebTestClient。以下示例显示了一个同时使用 @WebFluxTest 和 WebTestClient 的类：

此设置仅受 WebFlux 应用程序支持，因为在模拟 Web 应用程序中使用 WebTestClient 目前仅适用于 WebFlux。

@WebFluxTest 无法检测通过功能 Web 框架注册的路由。为了在上下文中测试 RouterFunction bean，请考虑使用 @Import 或 @SpringBootTest 自行导入 RouterFunction。

@WebFluxTest 无法检测到自定义安全配置已注册为类型为 SecurityWebFilterChain 的 @Bean。要将其包括在测试中，您需要使用 @Import 或 @SpringBootTest 导入注册了 bean 的配置。

有时编写 Spring WebFlux 测试还不够；Spring Boot 可以帮助您运行 full end-to-end tests with an actual server。

Auto-configured Spring GraphQL Tests

Spring GraphQL 提供了一个专门的测试支持模块；您需要将其添加到项目中：

Maven
<dependencies>
	<dependency>
		<groupId>org.springframework.graphql</groupId>
		<artifactId>spring-graphql-test</artifactId>
		<scope>test</scope>
	</dependency>
	<!-- Unless already present in the compile scope -->
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-webflux</artifactId>
		<scope>test</scope>
	</dependency>
</dependencies>
Gradle
dependencies {
	testImplementation("org.springframework.graphql:spring-graphql-test")
	// Unless already present in the implementation configuration
	testImplementation("org.springframework.boot:spring-boot-starter-webflux")
}

此测试模块发送 {url-spring-graphql-docs}/#testing-graphqltester[GraphQlTester]。测试仪在测试中得到了广泛使用，因此务必熟悉它的使用。有 GraphQlTester 变体，Spring Boot 会根据测试类型自动配置它们：

  • ExecutionGraphQlServiceTester 在服务器端执行测试，没有客户端或传输

  • HttpGraphQlTester 执行带有对服务器的连接的客户端（可能存在或不存在一个实时服务器）的测试

Spring Boot 可帮助您使用 @GraphQlTest 注释测试 {url-spring-graphql-docs}/#controllers[Spring GraphQL 控制器]。@GraphQlTest 自动配置 Spring GraphQL 基础架构，而不涉及任何传输或服务器。这将扫描的 bean 限制为 @Controller、RuntimeWiringConfigurer、JsonComponent、Converter、GenericConverter、DataFetcherExceptionResolver、Instrumentation 和 GraphQlSourceBuilderCustomizer。使用 @GraphQlTest 注释时，不会扫描常规 @Component 和 @ConfigurationProperties bean。@EnableConfigurationProperties 用于包含 @ConfigurationProperties bean。

完整的自动配置列表可以通过 @GraphQlTest 启用。

通常，@GraphQlTest 仅限于一组控制器，并与 @MockBean 注释结合使用，以便为所需的协作者提供模拟实现。

：：include-code::GreetingControllerTests[]

@SpringBootTest 测试是完全集成测试，涉及整个应用程序。在使用随机或定义的端口时，将会配置一个实时服务器，并且将自动提供 HttpGraphQlTester bean，以便您可以使用它来测试服务器。在配置了 MOCK 环境时，您还可以通过使用 @AutoConfigureHttpGraphQlTester 标注测试类，来请求 HttpGraphQlTester bean：

：：include-code::GraphQlIntegrationTests[]

Auto-configured Data Cassandra Tests

您可以使用 @DataCassandraTest 来测试 Cassandra 应用程序。默认情况下，它会配置 CassandraTemplate、扫描 @Table 类，并配置 Spring Data Cassandra 存储库。使用 @DataCassandraTest 注释时，不会扫描常规 @Component 和 @ConfigurationProperties bean。@EnableConfigurationProperties 用于包含 @ConfigurationProperties bean。（有关如何将 Cassandra 与 Spring Boot 搭配使用的更多信息，请参见 "Cassandra"。）

完整的自动配置设置列表可以通过 @DataCassandraTest 启用。

以下示例显示了在 Spring Boot 中使用 Cassandra 测试的典型设置：

：：include-code::MyDataCassandraTests[]

Auto-configured Data Couchbase Tests

您可以使用 @DataCouchbaseTest 来测试 Couchbase 应用程序。默认情况下，它会配置 CouchbaseTemplate 或 ReactiveCouchbaseTemplate、扫描 @Document 类，并配置 Spring Data Couchbase 存储库。使用 @DataCouchbaseTest 注释时，不会扫描常规 @Component 和 @ConfigurationProperties bean。@EnableConfigurationProperties 用于包含 @ConfigurationProperties bean。（有关如何将 Couchbase 与 Spring Boot 搭配使用的更多信息，请参见本章前面的 "Couchbase"。）

完整的自动配置设置列表可以通过 @DataCouchbaseTest 启用。

以下示例显示了在 Spring Boot 中使用 Couchbase 测试的典型设置：

：：include-code::MyDataCouchbaseTests[]

Auto-configured Data Elasticsearch Tests

您可以使用 @DataElasticsearchTest 来测试 Elasticsearch 应用程序。默认情况下，它会配置 ElasticsearchRestTemplate、扫描 @Document 类，并配置 Spring Data Elasticsearch 存储库。使用 @DataElasticsearchTest 注释时，不会扫描常规 @Component 和 @ConfigurationProperties bean。@EnableConfigurationProperties 用于包含 @ConfigurationProperties bean。（有关如何将 Elasticsearch 与 Spring Boot 搭配使用的更多信息，请参见本章前面的 "Elasticsearch"。）

完整的自动配置设置列表可以通过 @DataElasticsearchTest 启用。

以下示例显示了在 Spring Boot 中使用 Elasticsearch 测试的典型设置：

：：include-code::MyDataElasticsearchTests[]

Auto-configured Data JPA Tests

您可以使用`@DataJpaTest`注释来测试JPA应用程序。默认情况下，它扫描`@Entity`类和配置Spring Data JPA存储库。如果类路径中存在嵌入式数据库，它也会配置一个。通过将`spring.jpa.show-sql`属性设置为`true`，默认情况下会记录SQL查询。这可以使用注释的`showSql`属性禁用。

使用`@DataJpaTest`注释时，不会扫描常规`@Component`和`@ConfigurationProperties`bean。@EnableConfigurationProperties`可用于包含@ConfigurationProperties`bean。

由`@DataJpaTest`启用的自动配置设置的列表可以found in the appendix。

默认情况下，data JPA测试是事务性的，并在每个测试结束时回滚。有关更多详细信息，请参阅Spring Framework参考文档中的{url-spring-framework-docs}/testing/testcontext-framework/tx.html#testcontext-tx-enabling-transactions[相关章节]。如果不是您想要的内容，您可以按以下方式禁用测试或整个类的交易管理：

数据JPA测试也可能注入 {code-spring-boot-test-autoconfigure-src}/orm/jpa/TestEntityManager.java[TestEntityManager] bean，它提供了专为测试而设计的标准JPA`EntityManager`的替代方案。

还可以通过添加`@AutoConfigureTestEntityManager`将`TestEntityManager`自动配置到任何基于Spring的测试类。这样做时，请确保您的测试正在事务中运行，例如通过在您的测试类或方法上添加`@Transactional`。

如果需要，还提供了一个`JdbcTemplate`。以下示例显示了正在使用的`@DataJpaTest`注释：

基于内存的嵌入式数据库通常适用于测试，因为它们速度快且无需安装。但是，如果您更愿意针对实际数据库运行测试，则可以使用`@AutoConfigureTestDatabase`注释，如以下示例所示：

Auto-configured JDBC Tests

@JdbcTest`类似于@DataJpaTest`，但适用于仅需要`DataSource`的测试并且不使用Spring Data JDBC。默认情况下，它配置了一个内存中的嵌入式数据库和一个`JdbcTemplate`。使用`@JdbcTest`注释时，不会扫描常规`@Component`和`@ConfigurationProperties`bean。@EnableConfigurationProperties`可用于包含@ConfigurationProperties`bean。

由`@JdbcTest`启用的自动配置的列表可以found in the appendix。

默认情况下，JDBC测试是事务性的，并在每个测试结束时回滚。有关更多详细信息，请参阅Spring Framework参考文档中的{url-spring-framework-docs}/testing/testcontext-framework/tx.html#testcontext-tx-enabling-transactions[相关章节]。如果不是您想要的内容，您可以按以下方式禁用测试或整个类的交易管理：

如果您更喜欢让您的测试针对实际数据库运行，则可以使用`@AutoConfigureTestDatabase`注释，方法与`@DataJpaTest`相同。（请参见“Auto-configured Data JPA Tests”。）

Auto-configured Data JDBC Tests

@DataJdbcTest`类似于@JdbcTest`，但适用于使用Spring Data JDBC存储库的测试。默认情况下，它配置了一个基于内存的嵌入式数据库、JdbcTemplate`和Spring Data JDBC存储库。使用@DataJdbcTest`注释时，只扫描`AbstractJdbcConfiguration`子类，常规`@Component`和`@ConfigurationProperties`bean不被扫描。@EnableConfigurationProperties`可用于包含@ConfigurationProperties`bean。

由`@DataJdbcTest`启用的自动配置的列表可以found in the appendix。

默认情况下，Data JDBC测试是事务性的，并在每个测试结束时回滚。有关更多详细信息，请参阅Spring Framework参考文档中的{url-spring-framework-docs}/testing/testcontext-framework/tx.html#testcontext-tx-enabling-transactions[相关章节]。如果不是您想要的内容，您可以为测试或整个测试类禁用事务管理，例如shown in the JDBC example。

如果您更喜欢让您的测试针对实际数据库运行，则可以使用`@AutoConfigureTestDatabase`注释，方法与`@DataJpaTest`相同。（请参见“Auto-configured Data JPA Tests”。）

Auto-configured Data R2DBC Tests

@DataR2dbcTest 与 @DataJdbcTest 类似，但适用于使用 Spring Data R2DBC 存储库的测试。默认情况下，它会配置一个内存嵌入式数据库、一个 R2dbcEntityTemplate 和 Spring Data R2DBC 存储库。在使用 @DataR2dbcTest 注解时，不会扫描常规 @Component 和 @ConfigurationProperties bean。可以使用 @EnableConfigurationProperties 来包括 @ConfigurationProperties bean。

可以通过 found in the appendix 查询由 @DataR2dbcTest 启用的自动配置列表。

默认情况下，Data R2DBC 测试是非事务性的。

如果您更喜欢让您的测试针对实际数据库运行，则可以使用`@AutoConfigureTestDatabase`注释，方法与`@DataJpaTest`相同。（请参见“Auto-configured Data JPA Tests”。）

Auto-configured jOOQ Tests

你可以像使用 @JdbcTest 一样使用 @JooqTest，但适用于与 jOOQ 相关的测试。由于 jOOQ 严重依赖于与数据库架构相对应的基于 Java 的架构，因此使用了现有的 DataSource。如果你想在它替换为内存数据库，可以使用`@AutoConfigureTestDatabase`来覆盖那些设置。（有关在 Spring Boot 中使用 jOOQ 的更多信息，请参阅 "Using jOOQ"）。在使用 @JooqTest 注解时，不会扫描常规 @Component 和 @ConfigurationProperties bean。可以使用 @EnableConfigurationProperties 来包括 @ConfigurationProperties bean。

可以通过 found in the appendix 查询由 @JooqTest 启用的自动配置列表。

@JooqTest 配置了 DSLContext。以下示例展示了正在使用的 @JooqTest 注解：

默认情况下，JOOQ 测试是事务性的，并在每个测试结束时回滚。如果你不想要这样做，你可以禁用测试或整个测试类的事务管理，例如 shown in the JDBC example。

Auto-configured Data MongoDB Tests

你可以使用 @DataMongoTest 来测试 MongoDB 应用程序。默认情况下，它会配置一个 MongoTemplate、扫描 @Document 类，并配置 Spring Data MongoDB 存储库。在使用 @DataMongoTest 注解时，不会扫描常规 @Component 和 @ConfigurationProperties bean。可以使用 @EnableConfigurationProperties 来包括 @ConfigurationProperties bean。（有关在 Spring Boot 中使用 MongoDB 的更多信息，请参阅 "MongoDB"）。

可以通过 found in the appendix 查询由 @DataMongoTest 启用的自动配置设置列表。

以下类示例展示了正在使用的 @DataMongoTest 注解：

Auto-configured Data Neo4j Tests

你可以使用 @DataNeo4jTest 来测试 Neo4j 应用程序。默认情况下，它会扫描 @Node 类，并配置 Spring Data Neo4j 存储库。在使用 @DataNeo4jTest 注解时，不会扫描常规 @Component 和 @ConfigurationProperties bean。可以使用 @EnableConfigurationProperties 来包括 @ConfigurationProperties bean。（有关在 Spring Boot 中使用 Neo4J 的更多信息，请参阅 "Neo4j"）。

可以通过 found in the appendix 查询由 @DataNeo4jTest 启用的自动配置设置列表。

以下示例展示了在 Spring Boot 中使用 Neo4J 测试的典型设置：

默认情况下，Data Neo4j 测试是事务性的，并在每个测试结束时回滚。有关更多详细信息，请参阅 Spring Framework 参考文档中的[相关部分](docs/testing/testcontext-framework/tx.html#testcontext-tx-enabling-transactions)。如果你不想要这样做，你可以为某个测试或整个类禁用事务管理，如下所示：

不支持通过响应访问进行的事务测试。如果你使用这种样式，你必须如上所述配置 @DataNeo4jTest 测试。

Auto-configured Data Redis Tests

您可以使用 @DataRedisTest 来测试 Redis 应用程序。默认情况下，它会扫描 @RedisHash 课程和配置 Spring Data Redis 存储库。使用 @DataRedisTest 注释时，不会扫描常规的 @Component 和 @ConfigurationProperties bean。@EnableConfigurationProperties 可用于包含 @ConfigurationProperties bean。（有关将 Redis 与 Spring Boot 配合使用的更多信息，请参阅“Redis”。）

可以通过 found in the appendix 列出由 @DataRedisTest 启用的自动配置设置。

以下示例演示了 @DataRedisTest 注释的使用方法：

Auto-configured Data LDAP Tests

您可以使用 @DataLdapTest 来测试 LDAP 应用程序。默认情况下，它会配置内存中的嵌入式 LDAP（如果可用），配置一个 LdapTemplate，扫描 @Entry 课程和配置 Spring Data LDAP 存储库。使用 @DataLdapTest 注释时，不会扫描常规的 @Component 和 @ConfigurationProperties bean。@EnableConfigurationProperties 可用于包含 @ConfigurationProperties bean。（有关将 LDAP 与 Spring Boot 配合使用的更多信息，请参阅“LDAP”。）

可以通过 found in the appendix 列出由 @DataLdapTest 启用的自动配置设置。

以下示例演示了 @DataLdapTest 注释的使用方法：

内存中的嵌入式 LDAP 通常适用于测试，因为它速度快且不需要任何开发人员安装。但是，如果您希望针对真正的 LDAP 服务器运行测试，则应该排除嵌入式 LDAP 自动配置，如下面的示例中所示：

Auto-configured REST Clients

您可以使用 @RestClientTest 注释来测试 REST 客户端。默认情况下，它会自动配置 Jackson、GSON 和 Jsonb 支持，配置一个 RestTemplateBuilder 和一个 RestClient.Builder，并添加对 MockRestServiceServer 的支持。使用 @RestClientTest 注释时，不会扫描常规的 @Component 和 @ConfigurationProperties bean。@EnableConfigurationProperties 可用于包含 @ConfigurationProperties bean。

可以通过 found in the appendix 列出由 @RestClientTest 启用的自动配置设置。

您想要测试的特定 bean 应当使用 @RestClientTest 的 value 或 components 属性进行指定。

在被测 bean 中使用 RestTemplateBuilder 时，如果在构建 RestTemplate 时已调用 RestTemplateBuilder.rootUri(String rootUri)，则应该从 MockRestServiceServer 预期中省略根 URI，如下面的示例所示：

在被测 bean 中使用 RestClient.Builder 时，或在不调用 rootUri(String rootURI) 的情况下使用 RestTemplateBuilder 时，必须在 MockRestServiceServer 预期中使用完整的 URI，如下面的示例所示：

Auto-configured Spring REST Docs Tests

可以使用 @AutoConfigureRestDocs 注释在测试中结合 Mock MVC、REST Assured 或 WebTestClient 使用 {url-spring-restdocs-site}[Spring REST Docs]。它无需在 Spring REST Docs 中使用 JUnit 扩展。

可以使用 @AutoConfigureRestDocs 来覆盖默认输出目录（如果您使用的是 Maven，则为 target/generated-snippets；如果您使用的是 Gradle，则为 build/generated-snippets）。它还可用于配置显示在任何已记录 URI 中的主机、方案和端口。

Auto-configured Spring REST Docs Tests With Mock MVC

@AutoConfigureRestDocs 会自定义 MockMvc bean，以在对基于 servlet 的 web 应用程序进行测试时使用 Spring REST Docs。可以通过使用 @Autowired 注入该 bean，并且在测试中可以按平常使用 Mock MVC 和 Spring REST Docs 时的方式使用它，如下面的示例所示：

在测试中使用 @AutoConfigureRestDocs 代码：MyUserDocumentationTests[]

如果需要对 Spring REST Docs 配置拥有比通过 @AutoConfigureRestDocs 的属性提供的更大的控制权，那么可以使用 RestDocsMockMvcConfigurationCustomizer bean，如下面的示例所示：

在测试中使用 RestDocsMockMvcConfigurationCustomizer 代码：MyRestDocsConfiguration[]

如果您希望利用 Spring REST Docs 对参数化输出目录的支持，则可以创建一个 RestDocumentationResultHandler bean。自动配置使用此结果处理程序调用 alwaysDo，从而导致每个 MockMvc 调用自动生成默认片段。以下示例显示了 RestDocumentationResultHandler 定义：

Auto-configured Spring REST Docs Tests With WebTestClient

在测试响应式 Web 应用程序时，@AutoConfigureRestDocs 还可以与 WebTestClient 一起使用。您可以使用 @Autowired 注入它，并在测试中使用它，就像在使用 @WebFluxTest 和 Spring REST Docs 时通常会做的那样，如下例所示：

如果您需要对 @AutoConfigureRestDocs 的属性提供的 Spring REST Docs 配置进行更多控制，则可以使用 RestDocsWebTestClientConfigurationCustomizer bean，如下例所示：

在测试中使用 RestDocsMockMvcConfigurationCustomizer 代码：MyRestDocsConfiguration[]

如果您希望利用 Spring REST Docs 对参数化输出目录的支持，则可以使用 WebTestClientBuilderCustomizer 为每个实体交换结果配置使用者。以下示例显示了此类 WebTestClientBuilderCustomizer 的定义：

Auto-configured Spring REST Docs Tests With REST Assured

@AutoConfigureRestDocs 使得预先配置为使用 Spring REST Docs 的 RequestSpecification bean 可用于您的测试。您可以使用 @Autowired 注入它，并在测试中使用它，就像在使用 REST Assured 和 Spring REST Docs 时通常会做的那样，如下例所示：

在测试中使用 @AutoConfigureRestDocs 代码：MyUserDocumentationTests[]

如果您需要对 @AutoConfigureRestDocs 的属性提供的 Spring REST Docs 配置进行更多控制，则可以使用 RestDocsRestAssuredConfigurationCustomizer bean，如下例所示：

在测试中使用 RestDocsMockMvcConfigurationCustomizer 代码：MyRestDocsConfiguration[]

Auto-configured Spring Web Services Tests

Auto-configured Spring Web Services Client Tests

您可以使用 @WebServiceClientTest 测试使用 Spring Web Services 项目调用 Web 服务的应用程序。默认情况下，它配置一个模拟 WebServiceServer bean 并自动自定义您的 WebServiceTemplateBuilder。（有关在 Spring Boot 中使用 Web 服务的更多信息，请参见 "Web Services"。）

可以 found in the appendix 由 @WebServiceClientTest 启用的自动配置设置列表。

以下示例显示 @WebServiceClientTest 注释的使用情况：

Auto-configured Spring Web Services Server Tests

您可以使用 @WebServiceServerTest 测试使用 Spring Web Services 项目实现 Web 服务的应用程序。默认情况下，它配置一个 MockWebServiceClient bean，该 bean 可用于调用您的 Web 服务端点。（有关在 Spring Boot 中使用 Web 服务的更多信息，请参见 "Web Services"。）

可以 found in the appendix 由 @WebServiceServerTest 启用的自动配置设置列表。

以下示例展示了 @WebServiceServerTest 注释的用法：

Additional Auto-configuration and Slicing

每个 slice 都提供一个或多个 @AutoConfigure…​ 注释，主要定义作为 slice 一部分包含的自动配置。可以通过创建定制的 @AutoConfigure…​ 注释或在测试中添加 @ImportAutoConfiguration 来针对每个测试添加额外的自动配置，如下面的示例所示：

务必不要使用常规 @Import 注释来导入自动配置，因为它们通过 Spring Boot 以特定方式进行处理。

或者，可以通过将额外的自动配置注册到按 META-INF/spring 存储的文件中针对任何 slice 注释的使用添加这些配置，如下面的示例所示：

META-INF/spring/org.springframework.boot.test.autoconfigure.jdbc.JdbcTest.imports
com.example.IntegrationAutoConfiguration

在此示例中，com.example.IntegrationAutoConfiguration 已在使用 @JdbcTest 注释的所有测试上启用。

您可以在此文件中使用注释加上 #。

slice 或 @AutoConfigure…​ 注释可以以这种方式自定义，只要它使用 @ImportAutoConfiguration 元注释。

User Configuration and Slicing

如果您以合理的方式使用 structure your code，那么您的 @SpringBootApplication 类将作为测试配置使用 used by default。

因此，对应用程序主类重要的不是在其中散布特定的于其功能区域的设置配置。

假设您正在使用 Spring Data MongoDB，您依赖其自动配置，并且您已启用审核。您可以按如下方式定义您的 @SpringBootApplication：

由于此类是测试的源配置，因此任何 slice 测试都会尝试实际启用 Mongo 审核，但这绝对不是您想执行的操作。建议的方法是将该特定区域的配置移到一个独立的 @Configuration 类中，该类与您的应用程序处在同一级别，如下面的示例所示：

根据您的应用程序的复杂性，您可能拥有一个用于定制的单一的 @Configuration 类或每个域区域一个类。后者方法让您可以使用 @Import 注释在必要时在其中一个测试中启用它。有关您可能希望在什么时候对 slice 测试启用特定的 @Configuration 类，请参见 this how-to section。

测试 slice 将 @Configuration 类排除在扫描之外。例如，对于 @WebMvcTest，以下配置将不会在由测试 slice 加载的应用程序上下文中包含给定的 WebMvcConfigurer bean：

但是，以下配置将导致测试 slice 加载定制的 WebMvcConfigurer。

混乱的另一个来源是类路径扫描。假设在以明智的方式构建代码时，需要扫描其他包。应用程序可能类似于以下代码：

这样做实际上会覆盖默认组件扫描指令，其副作用是扫描这两个包，而不管你选择什么切片。例如，a`@DataJpaTest`似乎突然扫描了应用程序的组件和用户配置。同样，将自定义指令移到单独的类中是解决此问题的不错方法。

如果这不是你的选择，则可以在测试层次结构的某个位置创建一个`@SpringBootConfiguration`，以便改用。或者，你可以为测试指定一个来源，以禁用查找默认来源的行为。

Using Spock to Test Spring Boot Applications

Spock 2.2 or later can be used to test a Spring Boot application.To do so, add a dependency on a -groovy-4.0 version of Spock’s spock-spring module to your application’s build.spock-spring integrates Spring’s test framework into Spock.See the documentation for Spock’s Spring module for further details.

Testcontainers

Testcontainers library provides a way to manage services running inside Docker containers.It integrates with JUnit, allowing you to write a test class that can start up a container before any of the tests run.Testcontainers is especially useful for writing integration tests that talk to a real backend service such as MySQL, MongoDB, Cassandra and others.

Testcontainers can be used in a Spring Boot test as follows:

这将在运行任何测试之前启动运行 Neo4j 的 docker 容器（如果 Docker 在本地运行）。在大多数情况下，你需要配置应用程序以连接到容器中运行的服务。

Service Connections

服务连接是到任何远程服务的连接。Spring Boot 的自动配置可以获取服务连接的详细信息，并使用它们来建立与远程服务的连接。执行此操作时，连接详细信息优先于任何与连接相关的配置属性。

使用 Testcontainers 时，可以通过在测试类中注释容器字段为容器中运行的服务自动创建连接详细信息。

感谢`@ServiceConnection`，以上配置允许应用程序中的 Neo4j 相关 bean 与 Testcontainers 管理的 Docker 容器中运行的 Neo4j 通信。这是通过自动定义一个`Neo4jConnectionDetails`bean 来完成的，然后 Neo4j 自动配置使用该 bean，并覆盖任何与连接相关的配置属性。

你需要添加`spring-boot-testcontainers`module 作为测试依赖项，才能将服务连接与 Testcontainers 一起使用。

服务连接注释由注册为`spring.factories`的`ContainerConnectionDetailsFactory`类处理。`ContainerConnectionDetailsFactory`可以根据特定的`Container`子类或 Docker 映像名称创建一个`ConnectionDetails`bean。

以下服务连接工厂在中提供`spring-boot-testcontainers`jar：

Connection Details Matched on

ActiveMQConnectionDetails

名为 "symptoma/activemq" 或`ActiveMQContainer`的容器

ArtemisConnectionDetails

Containers of type ArtemisContainer

CassandraConnectionDetails

Containers of type CassandraContainer

CouchbaseConnectionDetails

Containers of type CouchbaseContainer

ElasticsearchConnectionDetails

Containers of type ElasticsearchContainer

FlywayConnectionDetails

Containers of type JdbcDatabaseContainer

JdbcConnectionDetails

Containers of type JdbcDatabaseContainer

KafkaConnectionDetails

类型为`KafkaContainer`或`RedpandaContainer`的容器

LiquibaseConnectionDetails

Containers of type JdbcDatabaseContainer

MongoConnectionDetails

Containers of type MongoDBContainer

Neo4jConnectionDetails

Containers of type Neo4jContainer

OtlpMetricsConnectionDetails

Containers named "otel/opentelemetry-collector-contrib"

OtlpTracingConnectionDetails

Containers named "otel/opentelemetry-collector-contrib"

PulsarConnectionDetails

Containers of type PulsarContainer

R2dbcConnectionDetails

类型为`MariaDBContainer`、MSSQLServerContainer、@"22":、`OracleContainer`或`PostgreSQLContainer`的容器

RabbitConnectionDetails

Containers of type RabbitMQContainer

RedisConnectionDetails

Containers named "redis"

ZipkinConnectionDetails

Containers named "openzipkin/zipkin"

默认情况下，将为给定的`Container`创建所有适用的连接详细信息 Bean。例如，PostgreSQLContainer`将同时创建`JdbcConnectionDetails`和`R2dbcConnectionDetails 。 如果你只想创建适用的类型的子集，你可以使用`@ServiceConnection`的`type`属性。

默认情况下，`Container.getDockerImageName()`用于获取用于查找连接详细信息的名称。只要 Spring Boot 能够获取`Container`的实例，这种方法就有效，就像在上面的示例中使用`static`字段一样。

如果你正在使用`@Bean`方法，Spring Boot 将不会调用 Bean 方法来获取 Docker 镜像名称，因为这会导致急切初始化问题。相反，Bean 方法的返回类型用于找出应该使用哪个连接详细信息。只要你使用类型化的容器，例如`Neo4jContainer`或`RabbitMQContainer`，这种方法就有效。如果你使用`GenericContainer`，例如在 Redis 中使用，这种方法将停止工作，如下面的示例所示：

Spring Boot 无法从`GenericContainer`中判断使用哪个容器镜像，因此必须使用`@ServiceConnection`中的`name`属性来提供该提示。

你还可以使用`@ServiceConnection`的`name`属性来覆盖将使用哪个连接详细信息，例如在使用自定义镜像时。如果你使用 Docker 镜像`registry.mycompany.com/mirror/myredis`，你将使用`@ServiceConnection(name="redis")来确保创建`RedisConnectionDetails。

Dynamic Properties

略微冗长但也是更灵活的服务连接的替代方法是`@DynamicPropertySource`。一个静态`@DynamicPropertySource`方法允许将动态属性值添加到 Spring Environment。

上述配置允许应用程序中的 Neo4j 相关 Bean 与在 Testcontainers 管理的 Docker 容器中运行的 Neo4j 通信。

Test Utilities

在测试应用程序时通常有用的几个测试实用程序类打包在`spring-boot`中。

ConfigDataApplicationContextInitializer

ConfigDataApplicationContextInitializer`是一个`ApplicationContextInitializer，你可以将其应用于你的测试以加载 Spring Boot `application.properties`文件。当你不需要 `@SpringBootTest`提供的全部功能集时，可以使用它，如下面的示例所示：

仅使用`ConfigDataApplicationContextInitializer`不提供对`@Value("${…​}")注入的支持。它的唯一作用是确保`application.properties`文件被加载到 Spring 的`Environment`中。对于@Value`支持，你需要另外配置一个`PropertySourcesPlaceholderConfigurer`或使用`@SpringBootTest`，它会自动为你配置一个。

TestPropertyValues

TestPropertyValues`让你可以快速将属性添加到`ConfigurableEnvironment`或`ConfigurableApplicationContext。你可以用`key=value`字符串来调用它，如下所示：

OutputCapture

OutputCapture`是一个 JUnit `Extension，你可以用它来捕获`System.out`和`System.err`输出。要使用它，请添加`@ExtendWith(OutputCaptureExtension.class)`并将`CapturedOutput`注入到你的测试类构造函数或测试方法中，如下所示：

TestRestTemplate

`TestRestTemplate`是 Spring 的`RestTemplate`的一个方便的替代品，它在集成测试中很有用。你可以获得一个原生的模板或发送基本 HTTP 认证（包含用户名和密码）的模板。在这两种情况下，该模板都是容错的。这意味着它不会通过在 4xx 和 5xx 错误中抛出异常，以一种对测试友好的方式行事。相反，可以通过返回的`ResponseEntity`及其状态代码来检测到此类错误。

Spring Framework 5.0 提供了一个新注解 WebTestClient，适用于 WebFlux integration tests 和 WebFlux and MVC end-to-end testing。与 TestRestTemplate 不同，它为断言提供了流畅的 API。

建议使用 Apache HTTP 客户端（版本 5.1 或更高版本），但这并非强制性的。如果类路径中存在该客户端，则 TestRestTemplate 会通过相应地配置客户端做出响应。如果确实使用 Apache HTTP 客户端，则会启用一些额外的测试友好型功能：

  • 不会遵循重定向（因此你可以断言响应位置）。

  • 忽略 cookie（因此模板是无状态的）。

TestRestTemplate 可以直接在你集成测试中实例化，如下面的示例所示：

或者，如果你在 WebEnvironment.RANDOM_PORT 或 WebEnvironment.DEFINED_PORT 中使用 @SpringBootTest 注解，则可以注入一个完全配置的 TestRestTemplate 并开始使用它。如果需要，可以通过 RestTemplateBuilder Bean 应用其他自定义。任何未指定主机和端口的 URL 会自动连接到嵌入式服务器，如下面的示例所示：