@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.
Move the registration of cleanup callbacks to the intermediate When type to avoid overloads of Scenario.stimulate(…). Also, to prevent multiple lambda-style parameters for ….stimulate(…) as they don't distinguish nice on the declaration side. Removed the varargs from ….publish(…) methods and wait for the actual request to add support for preparing, in transaction callbacks (potentially to be introduced as ….prepare(…) method).
The default acceptance criteria for state change expectations now also considers a boolean true as concluding method result.
