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:

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: