If Spring Modulith packages were explicitly configured as autoconfiguration or entity scan packages, the test autoconfiguration would fail as it previously attempted to manipulate an immutable list. We now create a copy of that list to fix this.
We now create artificial root application modules for all root packages to detect violations (for example, types located in root packages referring to module-internal types).
@ApplicationModuleTest is now meta-annotated with @SpringBootTest. This allows us to remove a couple of declarations that we actually had copied from it (such as the TestContextBootstrapper, the SpringExtension etc.)
The presence of the original annotation allow test-related auto-configuration to inspect @SprignBootTest for particular configuration. For example, we now alias the WebEnvironment to make it configurable for the test execution.
We now register a default customizer on the Scenario instances created to pick up an ExecutorService defined in the ApplicationContext so that customizations made to that are considered in the test execution.
We now avoid accessing the ApplicationContext from a BeforeAllCallback as this might cause the context initialization before other extensions had time to kick in.
The dedicated annotation allows using Scenario as test parameter in @SpringBootTest-based integration tests, too.
ScenarioParameterResolver now throws a better error message if a TransactionTemplate bean is missing from the ApplicationContext.
We now provide a ScenarioCustomizer that can be used to prepare Scenario instances for test methods with a common customizer. This avoids the need to call ….customize(…) for all Scenarios declared in a test class with the same logic.
We now use Spring Test Context's TestContextAnnotationUtils to lookup the @ApplicationModuleTest annotation to eventually bootstrap an ApplicationModules instance. That ensures that we find the annotation on JUnit 5's @Nested classes.
To make sure that we trigger transactional event listeners from Scenario based integration tests, we trigger stimulus executions using transactions configured to require a new transaction. This makes sure that Scenarios work in integration tests using @Transactional, of course circumventing the default rollback behavior of those transactions. There's no other way to implement this as we *need* to commit a transaction to trigger the delivery of transaction-bound events.
Fixed a bug in the handling of Scenario.stimulus(Supplier<T>) as for this, the Supplier handed into the method had not been executed transactionally at all.
