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.

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

Nested Class Summary

Nested Classes

Modifier and Type	Class	Description
static class	MatsTestContext.MatsSimpleTestInfrastructureContextInitializer	The 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.