Package io.mats3.spring.test
Annotation Interface MatsTestContext
@Target(TYPE)
@Retention(RUNTIME)
@ContextConfiguration(initializers=MatsSimpleTestInfrastructureContextInitializer.class)
@Import(MatsTestInfrastructureConfiguration.class)
@DirtiesContext(classMode=AFTER_CLASS)
@Documented
@MatsTestProfile
public @interface MatsTestContext
One-stop-shop for making simple Spring-based integration/unit tests of Mats endpoints (NOT utilizing SQL
Connections), automatically importing the configuration . The configuration is done in
MatsTestInfrastructureConfiguration
. This annotation can be put on a test-class, or on a
@Configuration class (typically a nested static class within the test-class).
Observe: If this "kitchen sink" annotation doesn't serve your needs, an alternative for quickly putting a
MatsFactory
into a Spring test context is to utilize the methods in TestSpringMatsFactoryProvider
within a @Bean
factory method.
The annotation, mostly via MatsTestInfrastructureConfiguration
, sets up the following:
- Meta-annotated with
DirtiesContext
, since the Spring Test Context caching system is problematic when one is handling static/global resources like what an external Message Queue broker is. Read more below. - The
@MatsTestInfrastructureConfiguration
is Meta-annotated with@EnableMats
, since you pretty obviously need that, and have better things to do than to write it in each test.
- A
MatsFactory
(making the @EnableMats happy), created usingTestSpringMatsFactoryProvider
. - The
MatsFactory
'sdefault
MatsInitiator
to initiate messages with. - A
MatsTestBrokerInterface
that "hooks in" to the underlying MQ instance, providing (for now) DLQ access. - A lazy-initialized
MatsFuturizer
, since this is often handy in tests. - A
MatsTestLatch
instance in the Spring Context, since when you need it, you need it both in the @Configuration class, and in the test-class - nice to already have an instance defined.
MatsTestBroker
supports, read its JavaDoc!). Had there been some
"deactivate"/"reactivate" events that could be hooked, we could have stopped the endpoints for the to-be-cached
Spring test context, before firing up a new Spring test context, and the restarted them when the context was picked
up and reused from the cache. Since such a solution does not seem to be viable, the only solution seems to be
dirtying of the context, thereby stopping it from being cached.-
Nested Class Summary
Nested ClassesModifier and TypeClassDescriptionstatic class
The reason for this obscure way to add theMatsTestInfrastructureConfiguration
(as opposed to just point to it with "classes=..") is as follows: Spring's testing integration has this feature where any static inner @Configuration class of the test class is automatically loaded.