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