io.mats3.spring.test

Annotation Type MatsTestContext

@Target(value=TYPE)
 @Retention(value=RUNTIME)
 @ContextConfiguration(initializers=MatsTestContext.MatsSimpleTestInfrastructureContextInitializer.class)
 @Import(value=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.

Beans that are put in the Spring test context:

• A MatsFactory (making the @EnableMats happy), created using TestSpringMatsFactoryProvider.
• The MatsFactory's default 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.

For some more background on the Context Caching: Read the Spring doc about Context Caching and read a "wont-fix" bug report describing how the contexts aren't destroyed due to caching. Since we're setting up active message queue consumers with their own threads on a (potentially) global Message Queue broker, the different contexts would mess each other up: The old consumers would still consume messages that the new test setup expected its consumers to take. For the in-memory broker case, a solution would be to set up a new message broker (with a new name) for each context (each instantiation of a new Spring context), but this would not solve the situation where we ran the tests against a process-external MQ (which 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.

See Also:

TestSpringMatsFactoryProvider, MatsTestDbContext, MatsTestInfrastructureConfiguration, MatsTestInfrastructureDbConfiguration