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
MatsFactoryinto a Spring test context is to utilize the methods in
@Beanfactory 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.
@MatsTestInfrastructureConfigurationis Meta-annotated with
@EnableMats, since you pretty obviously need that, and have better things to do than to write it in each test.
MatsFactory(making the @EnableMats happy), created using
MatsInitiatorto initiate messages with.
MatsTestBrokerInterfacethat "hooks in" to the underlying MQ instance, providing (for now) DLQ access.
- A lazy-initialized
MatsFuturizer, since this is often handy in tests.
MatsTestLatchinstance 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.
MatsTestBrokersupports, 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 SummaryModifier and TypeClassDescription
static classThe reason for this obscure way to add the
MatsTestInfrastructureConfiguration(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.