集成测试应用程序模块

Spring Modulith 允许运行集成测试，单独或与其他应用程序模块组合引导单个应用程序模块。 为了实现这一点，请将 Spring Modulith 测试Starters添加到您的项目中，如下所示spring-doc.cn

<dependency>
  <groupId>org.springframework.modulith</groupId>
  <artifactId>spring-modulith-starter-test</artifactId>
  <scope>test</scope>
</dependency>

并将 JUnit 测试类放在应用程序模块包或其任何子包中，并使用 ：@ApplicationModuleTestspring-doc.cn

应用程序模块集成测试类
package example.order;

@ApplicationModuleTest
class OrderIntegrationTests {

  // Individual test cases go here
}
package example.order

@ApplicationModuleTest
class OrderIntegrationTests {

  // Individual test cases go here
}

这将运行您的集成测试，类似于实现的运行，但引导实际上仅限于测试所在的应用程序模块。 如果为 to 配置日志级别，您将看到有关测试执行如何自定义 Spring Boot 引导的详细信息：@SpringBootTestorg.springframework.modulithDEBUGspring-doc.cn

应用程序模块集成测试引导程序的日志输出
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::       (v3.0.0-SNAPSHOT)

… - Bootstrapping @ApplicationModuleTest for example.order in mode STANDALONE (class example.Application)…
… - ======================================================================================================
… - ## example.order ##
… - > Logical name: order
… - > Base package: example.order
… - > Direct module dependencies: none
… - > Spring beans:
… -       + ….OrderManagement
… -       + ….internal.OrderInternal
… - Starting OrderIntegrationTests using Java 17.0.3 …
… - No active profile set, falling back to 1 default profile: "default"
… - Re-configuring auto-configuration and entity scan packages to: example.order.

请注意，输出如何包含有关测试运行中包含的模块的详细信息。 它创建应用程序模块，找到要运行的模块，并将自动配置、组件和实体扫描的应用程序限制到相应的包中。spring-doc.cn

Bootstrap 模式

应用程序模块测试可以在多种模式下引导：spring-doc.cn

  • STANDALONE（默认） — 仅运行当前模块。spring-doc.cn

  • DIRECT_DEPENDENCIES— 运行当前模块以及当前模块直接依赖的所有模块。spring-doc.cn

  • ALL_DEPENDENCIES— 运行当前模块和所依赖的整个模块树。spring-doc.cn

处理传出的依赖关系

当应用程序模块被引导时，它包含的 Spring bean 将被实例化。 如果这些模块包含跨模块边界的 bean 引用，则如果测试运行中未包含其他模块，则引导将失败（有关详细信息，请参见引导模式）。 虽然自然的反应可能是扩展所包含的应用程序模块的范围，但模拟目标 bean 通常是更好的选择。spring-doc.cn

模拟其他应用程序模块中的 Spring bean 依赖项
@ApplicationModuleTest
class InventoryIntegrationTests {

  @MockitoBean SomeOtherComponent someOtherComponent;
}
@ApplicationModuleTest
class InventoryIntegrationTests {

  @MockitoBean SomeOtherComponent someOtherComponent
}

Spring Boot 将为定义为的类型创建 bean 定义和实例，并将它们添加到测试运行的引导程序中。@MockitoBeanApplicationContextspring-doc.cn

如果你发现你的应用程序模块依赖于太多其他 bean 的 bean，这通常是它们之间高度耦合的标志。 应通过发布域事件来检查依赖项是否是替换的候选项。spring-doc.cn

定义集成测试场景

集成测试应用程序模块可能是一项相当复杂的工作。 特别是如果这些的集成基于异步、事务性事件处理，则处理并发执行可能会产生细微的错误。 此外，它还需要处理相当多的基础设施组件：并确保事件被发布并交付给事务监听器，Awaitility 处理并发，AssertJ 断言来制定对测试执行结果的期望。TransactionOperationsApplicationEventProcessorspring-doc.cn

为了简化应用程序模块集成测试的定义，Spring Modulith 提供了抽象，可以通过在声明为 的测试中将其声明为测试方法参数来使用。Scenario@ApplicationModuleTestspring-doc.cn

在 JUnit 5 测试中使用 APIScenario
@ApplicationModuleTest
class SomeApplicationModuleTest {

  @Test
  public void someModuleIntegrationTest(Scenario scenario) {
    // Use the Scenario API to define your integration test
  }
}
@ApplicationModuleTest
class SomeApplicationModuleTest {

  @Test
  fun someModuleIntegrationTest(scenario: Scenario) {
    // Use the Scenario API to define your integration test
  }
}

测试定义本身通常遵循以下框架：spring-doc.cn

  1. 定义了对系统的刺激。这通常是事件发布或模块公开的 Spring 组件的调用。spring-doc.cn

  2. 执行技术细节（超时等）的可选自定义spring-doc.cn

  3. 某些预期结果的定义，例如触发的另一个与某些条件匹配的应用程序事件，或者可以通过调用公开的组件来检测的模块的某些状态更改。spring-doc.cn

  4. 可选，对收到的事件或观察到的更改状态进行的其他验证。spring-doc.cn

Scenario公开了一个 API 来定义这些步骤并指导您完成定义。spring-doc.cn

将刺激定义为Scenario
// Start with an event publication
scenario.publish(new MyApplicationEvent(…)).…

// Start with a bean invocation
scenario.stimulate(() -> someBean.someMethod(…)).…
// Start with an event publication
scenario.publish(MyApplicationEvent(…)).…

// Start with a bean invocation
scenario.stimulate(Runnable { someBean.someMethod(…) }).…

事件发布和 bean 调用都将在事务回调中进行，以确保给定的事件或在 bean 调用期间发布的任何事件都将传递给事务性事件侦听器。 请注意，这将需要启动一个新事务，无论测试用例是否已经在事务中运行。 换句话说，由 stimulus 触发的数据库状态更改将永远不会回滚，必须手动清理。 请参阅用于此目的的方法。….andCleanup(…)spring-doc.cn

结果对象现在可以通过泛型方法或针对常见用例（如设置超时 （）的专用方法）自定义执行。….customize(…)….waitAtMost(…)spring-doc.cn

设置阶段将通过定义对刺激结果的实际期望来结束。 这可以是特定类型的事件，也可以是匹配器的进一步约束：spring-doc.cn

预期事件将作为操作结果发布
….andWaitForEventOfType(SomeOtherEvent.class)
 .matching(event -> …) // Use some predicate here
 .…
….andWaitForEventOfType(SomeOtherEvent.class)
 .matching(event -> …) // Use some predicate here
 .…

这些行设置最终执行将等待继续的完成标准。 换句话说，上面的示例将导致执行最终阻塞，直到达到默认超时或发布与定义的谓词匹配的 a。SomeOtherEventspring-doc.cn

执行基于事件的终端操作被命名，并允许选择性地访问发布的预期事件，或在原始刺激中定义的 bean 调用的结果对象。Scenario….toArrive…()spring-doc.cn

触发验证
// Executes the scenario
….toArrive(…)

// Execute and define assertions on the event received
….toArriveAndVerify(event -> …)
// Executes the scenario
….toArrive(…)

// Execute and define assertions on the event received
….toArriveAndVerify(event -> …)

单独查看步骤时，方法名称的选择可能看起来有点奇怪，但实际上它们在组合时读起来非常流畅。spring-doc.cn

完整定义Scenario
scenario.publish(new MyApplicationEvent(…))
  .andWaitForEventOfType(SomeOtherEvent.class)
  .matching(event -> …)
  .toArriveAndVerify(event -> …);
scenario.publish(new MyApplicationEvent(…))
  .andWaitForEventOfType(SomeOtherEvent::class.java)
  .matching { event -> … }
  .toArriveAndVerify { event -> … }

除了作为预期完成信号的事件发布之外，我们还可以通过在公开的组件之一上调用方法来检查应用程序模块的状态。 然后，该场景将如下所示：spring-doc.cn

预期状态更改
scenario.publish(new MyApplicationEvent(…))
  .andWaitForStateChange(() -> someBean.someMethod(…)))
  .andVerify(result -> …);
scenario.publish(MyApplicationEvent(…))
  .andWaitForStateChange { someBean.someMethod(…) }
  .andVerify { result -> … }

交给方法的将是方法调用返回的值，用于检测状态更改。 默认情况下，非值和非空 s 将被视为决定性的状态更改。 这可以通过使用 overload 来调整。result….andVerify(…)nullOptional….andWaitForStateChange(…, Predicate)spring-doc.cn

自定义场景执行

要自定义单个场景的执行，请调用 ：….customize(…)Scenariospring-doc.cn

自定义执行Scenario
scenario.publish(new MyApplicationEvent(…))
  .customize(conditionFactory -> conditionFactory.atMost(Duration.ofSeconds(2)))
  .andWaitForEventOfType(SomeOtherEvent.class)
  .matching(event -> …)
  .toArriveAndVerify(event -> …);
scenario.publish(MyApplicationEvent(…))
  .customize { it.atMost(Duration.ofSeconds(2)) }
  .andWaitForEventOfType(SomeOtherEvent::class.java)
  .matching { event -> … }
  .toArriveAndVerify { event -> … }

要全局自定义测试类的所有实例，请实现 a 并将其注册为 JUnit 扩展。ScenarioScenarioCustomizerspring-doc.cn

注册ScenarioCustomizer
@ExtendWith(MyCustomizer.class)
class MyTests {

  @Test
  void myTestCase(Scenario scenario) {
    // scenario will be pre-customized with logic defined in MyCustomizer
  }

  static class MyCustomizer implements ScenarioCustomizer {

    @Override
    Function<ConditionFactory, ConditionFactory> getDefaultCustomizer(Method method, ApplicationContext context) {
      return conditionFactory -> …;
    }
  }
}
@ExtendWith(MyCustomizer::class)
class MyTests {

  @Test
  fun myTestCase(scenario: Scenario) {
    // scenario will be pre-customized with logic defined in MyCustomizer
  }

  class MyCustomizer : ScenarioCustomizer {

    override fun getDefaultCustomizer(method: Method, context: ApplicationContext): UnaryOperator<ConditionFactory> {
      return UnaryOperator { conditionFactory -> … }
    }
  }
}

更改感知测试执行

从版本 1.3 开始，Spring Modulith 附带了一个 JUnit Jupiter 扩展，该扩展将优化测试的执行，因此将跳过不受项目更改影响的测试。 要启用该优化，请在测试范围内将工件声明为依赖项：spring-modulith-junitspring-doc.cn

<dependency>
  <groupId>org.springframework.modulith</groupId>
  <artifactId>spring-modulith-junit</artifactId>
  <scope>test</scope>
</dependency>

如果测试驻留在根模块、已发生更改的模块或传递依赖于已发生更改的模块中，则将选择执行测试。 在以下情况下，优化将停止优化执行：spring-doc.cn

  • 测试执行源自 IDE，因为我们假设执行是显式触发的。spring-doc.cn

  • 更改集包含对与构建系统相关的资源（、、 和 ）的更改。pom.xmlbuild.gradle(.kts)gradle.propertiessettings.gradle(.kts)spring-doc.cn

  • 更改集包含对任何 Classpath 资源的更改。spring-doc.cn

  • 该项目根本不包含更改（通常在 CI 构建中）。spring-doc.cn

要在 CI 环境中优化执行，您需要填充spring.modulith.test.reference-commit属性，该属性指向最后一个成功构建的提交，并确保该构建签出所有提交，直到引用提交。 然后，检测应用程序模块更改的算法将考虑该增量中更改的所有文件。 要覆盖项目修改检测，请通过 spring.modulith.test.file-modification-detector 属性声明 的实现。FileModificationDetectorspring-doc.cn