2-3. 配置测试

问题

您希望为Spring Boot应用程序的组件或部分编写一个测试。

解决方案

Spring Boot 扩展了 Spring Testing 框架的功能范围。它增加了对通过 Mockito 支持模拟和监视（spying）bean 的支持，并提供了 web 测试的自动配置。它还引入了通过引导所需部分（例如使用 @WebMvcTest 或 @JdbcTest）来测试应用程序切片的简便方法，或者使用 @SpringBootTest 编写完整的集成测试。

它是如何工作的

Spring Boot 也将自动配置扩展到了测试框架的部分。它与 Mockito 集成，以便轻松模拟（或监视）bean。它还为使用 Spring MockMvc 测试框架或基于 WebDriver 的测试提供了 web 测试的自动配置。

编写单元测试

首先，让我们为计算器的一个组件编写一个简单的单元测试，即 MultiplicationTest，它将测试 Multiplication 类。参见列表 2-13。

这是一个基础单元测试。一旦实例化了乘法，我们就调用它的方法，最后我们验证结果。第一个测试将测试它是否真的对 * 操作符有反应，而不是其他东西。第二个测试将测试实际的乘法逻辑。要使一个方法成为一个测试方法，你需要用 @Test 注解它。

在单元测试中模拟依赖

有时候一个类需要依赖项；然而，你希望你的测试只测试一个组件（在编写单元测试时）。Spring Boot 自动引入了 Mockito 框架。Mockito 是一个很好的库，用于模拟类并记录它们的行为。为计算器应用程序编写测试需要额外的组件，因为它将实际的计算委托给可用的操作类。为了测试计算器的正确行为，我们需要创建一个操作的模拟，并将其注入计算器中。参见列表 2-14。

在 @BeforeEach 注解的类中，我们通过调用 Mockito.mock 来模拟 Operation，并使用模拟的操作来构造 Calculator。模拟对象在测试方法中被用来拥有特定的行为。在第一个测试方法中，我们想要测试无法找到合适操作的情况，因此我们指示模拟对象在调用 handles 方法时返回 false。测试将预期抛出异常；如果异常发生，测试将成功。第二个测试是为了测试是否遵循了正确的流程；我们想要测试正确的行为。模拟对象被指示为 handles 方法返回 true 并为 apply 方法返回一个值。

使用Spring Boot进行集成测试

Spring Boot提供了几个注解来帮助测试。第一个是@SpringBootTest，它将测试转变为Spring Boot驱动的测试，这意味着测试上下文框架将搜索带有@SpringBootApplication注解的类（如果没有传递特定配置），并使用它来实际启动应用程序。参见列表2-15。

之前的测试将启动CalculatorApplication并注入完全配置的Calculator。然后我们可以编写一个测试，例如一个计算器无法处理的情况，并为其编写预期结果。

在进行计算时，输出会被打印到控制台。使用JUnit的OutputCaptureExtension扩展，我们还可以编写一个成功测试并测试已写入的输出。参见列表2-16。

@ExtendWith 将配置给定的JUnit扩展，在这个例子中是OutputCaptureExtension扩展，它随Spring Boot一起提供，并拦截System.out和System.err，以便可以对这些流上生成的输出编写断言。要检查输出，请使用CapturedOutput类。这个类可以被扩展自动注入到方法中。在这个例子中，我们进行乘法运算，输出应该反映这一点。

使用Spring Boot和模拟对象进行集成测试

Spring Boot使得在应用程序上下文中替换一个bean为模拟对象变得简单。为此，Spring Boot提供了@MockBean注解。参见列表2-17。

这将用一个模拟实例替换整个计算器。为了能够使用它，你需要使用常规的Mockito方式定义行为。当存在多个特定类型的bean时，你需要指定你想要替换的bean的name属性。参见列表2-18。

这将用一个模拟实例替换常规的加法bean，然后我们可以在这个实例上注册模拟行为。当找不到具有该名称的bean时，模拟的bean将被注册为该bean的新实例。参见列表2-19。

列表2-19. 带有名称的MockBean注解示例（不存在的bean）

这不会替换现有的bean，而是将一个bean添加到应用程序上下文中，结果是Calculator将能够处理的额外操作会增加。你可以使用Spring测试框架中的ReflectionTestUtils辅助类来测试这一点。参见列表2-20。

这将通过反射获取操作字段，并断言集合大小为3。当移除（或名称改为addition）@MockBean注解时，此测试将失败，因为现在只注册了两个操作。

使用模拟对象很简单。参见列表2-21。

在这里，我们指示Mockito在测试除法（/）时返回true，并在调用apply方法时返回一个值。接下来调用该方法，并断言输出是否符合测试的预期。

使用Spring Boot切片进行集成测试

除了使用@SpringBootTest注解外，你还可以测试应用程序的一部分。为此，Spring Boot提供了所谓的切片。使用专用的@*Test注解（见表2-2），它将加载一个仅包含所需配置部分的ApplicationContext。例如，使用@JdbcTest时，它将创建一个仅包含JDBC相关bean（如DataSource，JdbcTemplate等）的ApplicationContext。它不会创建所有不相关的bean，比如你的web服务器或web相关bean。

以 @WebMvcTest 为例，我们可以用它来测试一个控制器，而无需引导整个应用程序。清单 2-22 包含了一个示例控制器，允许我们通过 Web 执行计算。它将接受参数并调用计算器。有关控制器和与 Web 相关的食谱的更多信息，请参阅第 3 章和第 4 章。参见清单 2-22。

为了测试这个，我们可以在测试上使用 @WebMvcTest 注解，并使用一个模拟的 Calculator 实例，因为这不会是上下文的一部分。参见列表 2-23。

使用 @WebMvcTest(CalculatorController.class)，我们指示测试框架创建一个最小化的Spring Boot应用程序，其中包含CalculatorController所需的基于Web的类。它还将设置MockMvc，以便更容易地调用端点并进行验证。现在运行它时，它将引导一个仅包含Web相关部分和给定模拟的Spring Boot应用程序。当然，在这个小样本中，执行一个 @SpringBootTest 或一个 @WebMvcTest 没有太大区别，但在更大的应用程序中，性能差异将相当明显。这个示例当然适用于其他基于切片的测试。

使用Spring Boot Testing的Testcontainers

你可能听说过Testcontainers库，你可能想在你的Spring Boot应用程序中使用它进行测试。有了Testcontainers库，编写测试并使用你在生产中使用的实际数据库、消息解决方案或邮件提供商（以及更多）变得容易。因此，你不必退回到内存或嵌入式解决方案，而是获得在生产中使用的完整解决方案。Testcontainers使用Docker使其成为可能，并且默认情况下，它将容器的生命周期绑定到你的测试。

为了能够使用这个，你需要在你的依赖管理（Maven或Gradle）中添加一个依赖，spring-boot-testcontainers，并且你需要包括你想要利用的Testcontainers模块。我们正在使用的示例将利用一个PostgreSQL容器来执行一些JDBC查询；它还将利用前面提到的切片支持来设置一个基于JDBC的测试。参见列表2-24。

列表2-24. Testcontainers和PostgreSQL的Maven依赖项

我们将添加spring-boot-testcontainers依赖项以及PostgreSQL JDBC驱动程序和PostgreSQL以及JUnit Testcontainers模块。有了这些，我们可以使用@TestContainers注解来启动一个PostgreSQL数据库进行测试。参见列表2-25。

在测试中，我们添加了@Testcontainers，这是一个特殊的JUnit扩展，用于Testcontainers。它现在将检测带有@Container注解的字段，并自动启动它们。由于我们正在使用容器，我们需要指示Spring Boot使用它。对于JDBC，我们需要配置spring.datasource.url属性（以及用户名和密码）。为此，我们可以使用@DynamicPropertySource，它可以放在测试中的静态方法上，然后它可以从容器中检索设置并将它们注册为属性。

最后，请注意@AutoConfigureTestDatabase，这对于数据库驱动的测试是必需的，因为默认情况下Spring Boot会尝试启动一个嵌入式容器并将其用作数据源。如果我们没有添加这个，测试用例将会失败。现在当运行测试时，Testcontainers将会介入，下载并启动容器，然后执行测试。之后，容器将被停止并销毁。

尽管这有效且是一种使用Testcontainers的可行方法，但它可以变得更好。Spring Boot引入了一种所谓的服务连接。这是对你可以连接的各种不同服务的一种抽象，比如数据库或消息代理。为了使用这个功能，有一个名为@ServiceConnection的注解，可以放在你想要使用的容器上。使用这个注解时，你不需要添加一个方法来动态注册上下文的属性。参见列表2-26。

测试的行为仍然相同：下载容器（如果需要），启动容器，运行测试，然后停止并销毁容器。然而，不再需要显式配置属性。这减少了我们不得不编写和维护的代码量。

@ServiceConnection 注解并不适用于所有容器，只适用于一些众所周知的容器。在撰写本文时，以下容器得到支持：

? CassandraContainer 类型的容器

? CouchbaseContainer 类型的容器

? ElasticSearchContainer 类型的容器

? JdbcDatabaseContainer 类型的容器

? KafkaContainer/RedpandaContainer 类型的容器

? MongoDBContainer 类型的容器

? Neo4jContainer 类型的容器

? RabbitMQContainer 类型的容器

? 名为 redis 的容器

? 名为 openzipkin/zipkin 的容器

默认情况下，服务连接基础设施将使用 Container.getDockerImageName 来确定要公开哪些连接详情。这在使用自定义镜像（特别是基于名称而非类型的基础镜像）时可能会出现问题。对于这些情况，您可以指定@ServiceConnection的name属性以匹配正确的名称。

当有多个测试使用相同的容器时，您也可以在接口或抽象基类中指定这些容器，并让测试类导入/扩展它们。这样可以更容易地重用容器，并且您就不需要在每个需要它们的测试中定义容器了。另一个好处是，您也可以在运行Spring时使用这些容器，并且通过重用，您可以确保您的测试以及您的应用程序使用相同的容器（参见食谱2-6）。参见列表2-27。

接下来，你可以让你的测试类实现这个接口，以重用容器定义。参见列表 2-28。