3. 集成测试应用程序模块
Spring Modulith 允许运行集成测试,单独或与其他应用程序模块组合引导单个应用程序模块。
要实现此目的,请将 JUnit 测试类放在应用程序模块包或其任何子包中,并使用 :@ApplicationModuleTest
package example.order;
@ApplicationModuleTest
class OrderIntegrationTests {
// Individual test cases go here
}
这将运行您的集成测试,类似于实现的运行,但引导实际上仅限于测试所在的应用程序模块。
如果为 to 配置日志级别,您将看到有关测试执行如何自定义 Spring Boot 引导的详细信息:@SpringBootTest
org.springframework.modulith
DEBUG
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: 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.
请注意,输出如何包含有关测试运行中包含的模块的详细信息。 它创建应用程序模块模块,找到要运行的模块,并将自动配置、组件和实体扫描的应用限制到相应的包中。
3.1. 引导模式
应用程序模块测试可以在多种模式下引导:
-
STANDALONE
(默认) — 仅运行当前模块。 -
DIRECT_DEPENDENCIES
— 运行当前模块以及当前模块直接依赖的所有模块。 -
ALL_DEPENDENCIES
— 运行当前模块和所依赖的整个模块树。
3.2. 处理传出的依赖关系
当应用程序模块被引导时,它包含的 Spring bean 将被实例化。 如果这些模块包含跨模块边界的 bean 引用,则如果测试运行中未包含其他模块,则引导将失败(有关详细信息,请参见引导模式)。 虽然自然的反应可能是扩展所包含的应用程序模块的范围,但模拟目标 bean 通常是更好的选择。
@ApplicationModuleTest
class InventoryIntegrationTests {
@MockBean SomeOtherComponent someOtherComponent;
}
Spring Boot 将为定义为的类型创建 bean 定义和实例,并将它们添加到测试运行的引导程序中。@MockBean
ApplicationContext
如果你发现你的应用程序模块依赖于太多其他 bean 的 bean,这通常是它们之间高度耦合的标志。 应通过发布域事件来检查依赖项是否是替换的候选项(请参阅使用应用程序事件)。
3.3. 定义集成测试场景
集成测试应用程序模块可能是一项相当复杂的工作。
特别是如果这些的集成基于异步、事务性事件处理,则处理并发执行可能会产生细微的错误。
此外,它还需要处理相当多的基础设施组件:并确保事件被发布并交付给事务监听器,Awaitility 处理并发,AssertJ 断言来制定对测试执行结果的期望。TransactionOperations
ApplicationEventProcessor
为了简化应用程序模块集成测试的定义,Spring Modulith 提供了抽象,可以通过在声明为 的测试中将其声明为测试方法参数来使用。Scenario
@ApplicationModuleTest
Scenario
@ApplicationModuleTest
class SomeApplicationModuleTest {
@Test
public void someModuleIntegrationTest(Scenario scenario) {
// Use the Scenario API to define your integration test
}
}
测试定义本身通常遵循以下框架:
-
定义了对系统的刺激。这通常是事件发布或模块公开的 Spring 组件的调用。
-
执行技术细节(超时等)的可选自定义
-
某些预期结果的定义,例如触发的另一个与某些条件匹配的应用程序事件,或者可以通过调用公开的组件来检测的模块的某些状态更改。
-
可选,对收到的事件或观察到的更改状态进行的其他验证。
Scenario
公开 API 来定义这些步骤并指导您完成定义。
Scenario
// Start with an event publication
scenario.publish(new MyApplicationEvent(…)).…
// Start with a bean invocation
scenario.stimulate(() -> someBean.someMethod(…)).…
事件发布和 bean 调用都将在事务回调中进行,以确保给定的事件或在 bean 调用期间发布的任何事件都将传递给事务性事件侦听器。
请注意,这将需要启动一个新事务,无论测试用例是否已经在事务中运行。
换句话说,由 stimulus 触发的数据库状态更改将永远不会回滚,必须手动清理。
请参阅用于此目的的方法。….andCleanup(…)
结果对象现在可以通过泛型方法或针对常见用例(如设置超时 ()的专用方法)自定义执行。….customize(…)
….waitAtMost(…)
设置阶段将通过定义对刺激结果的实际期望来结束。 这可以是特定类型的事件,也可以是匹配器的进一步约束:
….andWaitForEventOfType(SomeOtherEvent.class)
.matching(event -> …) // Use some predicate here
.…
这些行设置最终执行将等待继续的完成标准。
换句话说,上面的示例将导致执行最终阻塞,直到达到默认超时或发布与定义的谓词匹配的 a。SomeOtherEvent
执行基于事件的终端操作被命名,并允许选择性地访问发布的预期事件,或在原始刺激中定义的 bean 调用的结果对象。Scenario
….toArrive…()
// Executes the scenario
….toArrive(…)
// Execute and define assertions on the event received
….toArriveAndVerify(event -> …)
单独查看步骤时,方法名称的选择可能看起来有点奇怪,但实际上它们在组合时读起来非常流畅。
Scenario
scenario.publish(new MyApplicationEvent(…))
.andWaitForEventOfType(SomeOtherEvent.class)
.matching(event -> …)
.toArriveAndVerify(event -> …);
除了作为预期完成信号的事件发布之外,我们还可以通过在公开的组件之一上调用方法来检查应用程序模块的状态。 然后,该场景将如下所示:
scenario.publish(new MyApplicationEvent(…))
.andWaitForStateChange(() -> someBean.someMethod(…)))
.andVerify(result -> …);
交给方法的将是方法调用返回的值,用于检测状态更改。
默认情况下,非值和非空 s 将被视为决定性的状态更改。
这可以通过使用 overload 来调整。result
….andVerify(…)
null
Optional
….andWaitForStateChange(…, Predicate)
3.3.1. 自定义场景执行
要自定义单个场景的执行,请调用 :….customize(…)
Scenario
Scenario
scenario.publish(new MyApplicationEvent(…))
.customize(it -> it.atMost(Duration.ofSeconds(2)))
.andWaitForEventOfType(SomeOtherEvent.class)
.matching(event -> …)
.toArriveAndVerify(event -> …);
要全局自定义测试类的所有实例,请实现 a 并将其注册为 JUnit 扩展。Scenario
ScenarioCustomizer
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 it -> …;
}
}
}