Introduce declarative customization of ApplicationContext before refresh in the TestContext framework [SPR-12603]

[spring-projects-issues]

Josiah Haswell opened SPR-12603 and commented

It would be very nice for creating custom test annotations if we could get access to the GenericApplicationContext before it's loaded.

For instance:

I'm creating Cassandra and Datomic unit-testing support. I would like to generate schemata and import data before a test class is run, then clean up after a test is finished. Consider the following scenario:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
@CassandraTest(
        configurationFile = "cassandra.yaml",
        timeout = 3600,
        port = 9143,
        host = "localhost",
        clusterName = "cluster"
)
public class CassandraPersistenceTestCase {

    @Configuration
    static class Config {
        // Cassandra configuration ...
    }

    @Autowired
    Cluster cluster;

    // test methods ...

}

In this scenario, I would like to use the annotation @CassandraTest on CassandraPersistenceTestCase to:

1. Set up an embedded Cassandra instance
2. Access the application context to register a Cluster configured from the annotation so that I may inject it into the test case.

If I use the TestExecutionListener APIs, then I have access to the PersistenceTestCase class, but only after the ApplicationContext has been refreshed.

If I use the ApplicationContextInitializer APIs, then I can access the ApplicationContext before it has been refreshed, but I cannot easily access the class annotated by CassandraTest.

I could implement all of this very easily if I could only get access to a subclass of the AbstractGenericContextLoader (specifically the customizeContext method), but everything in the call chain is package-local. I could even work around this if TestContextManager were an interface or an abstract superclass, but it isn't.

My proposal would be to introduce the following classes:

@Retention(RetentionPolicy.RUNTIME)
public @interface ContextDecorators {

    Class<? extends ContextDecorator>[] value() default {};
}

interface ContextDecorator {

    void decorate(TestContext context);
}

Then, in SpringJUnit4ClassRunner, check to see if that annotation exists on the test class. If it does, route it to an implementation of customizeContext() in AbstractGenericContextLoader that applies each ContextDecorator to that context.

This would be minimally invasive and not change the existing behavior at all if the annotation is omitted.

I will submit a pull request along these lines if no one has any objections, or if no superior alternatives are available.

---

Affects: 3.2 GA

Issue Links:

• Introduce ContextCustomizer API in the TestContext framework [SPR-13998] #18571 Introduce ContextCustomizer API in the TestContext framework
• Introduce ContextCustomizer API in the TestContext framework [SPR-13998] #18571 Introduce ContextCustomizer API in the TestContext framework ("is superseded by")

[spring-projects-issues]

Sam Brannen commented

This proposal is very similar to Spring's existing support for the ApplicationContextInitializer API.

In fact, your proposed ContextDecorator is basically identical to the API for ApplicationContextInitializer.

Please take a look at ApplicationContextInitializer - which is configured via @ContextConfiguration(initializers=...) - and let us know if that meets your needs.

Note however that initializers are invoked in AbstractGenericContextLoader.loadContext(MergedContextConfiguration) before bean definitions are loaded, etc.

If you truly require access to the context immediately prior to refresh, you will have to extend one of the concrete subclasses of AbstractGenericContextLoader and override the customizeContext() method.

As an alternative, you should consider implementing a custom TestExecutionListener and registering it via @TestExecutionListeners.

Please let us know your thoughts in light of this additional information.

[spring-projects-issues]

Sam Brannen commented

As an aside, you mentioned that you would like to create custom test annotations, but your proposed ContextDecorator API does not provide a way to access the test class or test method that is currently being executed. It only provides implementers access to the ApplicationContext. So I don't see how you intend to perform any actions based on custom test annotations.

In general, if you wish to provide additional functionality to tests based on custom test annotations, you should implement a TestExecutionListener: a TestExecutionListener is given a reference to the current TestContext which provides access to the test class and test method.

[spring-projects-issues]

Josiah Haswell commented

Hi Sam,

I've edited the issue to provide more information. Both APIs do almost what I want, but not quite. You are correct that my proposal would be inadequate, but I've edited it to fix the problem. Comparing them, TestExecutionListener is closest, but I would need to be able to specify that I wanted access to the TestContext before the ApplicationContext has been refreshed (at the same time as ApplicationContextInitializer would be applied would work). Would it be preferable to add an option to the TestExecutionListeners annotation to specify when the listeners would be applied? Or, more generally, would it be possible to modify the annotation such that you could configure when groups of listeners would be applied? E.g.

@TestExecutionListeners({
@TestExecutionListener(
applyDuring = LifeCycle.BEFORE_REFRESH,
type = MyExecutionListener.class)

@TestExecutionListener(
applyDuring = LifeCycle.AFTER_INITIALIZATION,
type = MyOtherExecutionListener.class)
})
class MyTest{}

The problem with this is that it would change the existing APIs.

[spring-projects-issues]

Josiah Haswell commented

I've managed to work around this using BeanPostProcessors. There's significantly more effort involved in this route, but there is a workaround. I would like to leave this open as I feel like something along these lines would be valuable to the project, but I'm dropping the priority to minor given that there is a workaround.

[spring-projects-issues]

Sam Brannen commented

Access the application context to register a Cluster configured from the annotation so that I may inject it into the test case.

Is the Cluster intended to be injected into any Spring beans (other than just the test instance) managed by the ApplicationContext?

If not, then there are certainly easier ways to achieve your goal... like invoking a method on or setting a field in the test instance (which you can access via the TestContext in a TestExecutionListener). In fact, people often define an interface (e.g., ClusterAwareTest with a single setCluster(Cluster) method) that test classes can implement, and a corresponding custom TestExecutionListener that supports the interface and injects the desired components without the need for the component to be registered in the Spring ApplicationContext.

Would something like that be a more suitable solution for you?

[spring-projects-issues]

Sam Brannen commented

Would it be preferable to add an option to the TestExecutionListeners annotation to specify when the listeners would be applied? Or, more generally, would it be possible to modify the annotation such that you could configure when groups of listeners would be applied?

No, the TestExecutionListener API itself defines when callback methods must be invoked. Just see the names and documentation of each method in the TestExecutionListener interface.

[spring-projects-issues]

Josiah Haswell commented

The cluster in this example is intended to be injected into every bean referencing a cluster, and so that approach doesn't quite work. I could create the ClusterAware interface per your proposal and apply it to each bean, but I don't care much for this approach because, in a test environment, there are many configurations for clusters intended to test different aspects of interactions with a complex system. For some tests, clusters are mocks. For others, clusters are carefully-tuned production-level environments. In deployment, every bean in a given application instance has access to the same cluster, and so I do not necessarily want to clutter the application with an artifact of testing.

A last alternative is to create different configurations for each type of cluster. This also does about 95% of what I want it to do, but doesn't quite feel as nice, and I feel is more vulnerable to misuse by engineers.

Finally, it's not immediately clear from the documentation of TestExecutionListener why you should not be able to apply a listener during a certain phase in the Spring wiring lifecycle. The interface only specifies when each method is called relative to the test execution, except for the prepareTestInstance which is clearly called post-refresh.

[spring-projects-issues]

Sam Brannen commented

Josiah Haswell, you may be interested in the support recently introduced in conjunction with #18571.

The ContextCustomizer is similar to your proposed ContextDecorator, but ContextCustomizer is primarily targeted at third-party libraries (e.g., Spring Boot).

In any case, please let us know if ContextCustomizer meets your needs.

[spring-projects-issues]

Josiah Haswell commented

Hi Sam,

Thanks for the response. I've successfully ported the solution I had over to this, so it definitely meets my needs. You can close this issue now (I don't have permissions, I think)

Thanks!

Josiah

[spring-projects-issues]

Sam Brannen commented

I've successfully ported the solution I had over to this, so it definitely meets my needs.

Awesome! Great to hear it works for you, and thanks for letting us know.

You can close this issue now (I don't have permissions, I think)

Will do.

Cheers,

Sam

[spring-projects-issues]

Sam Brannen commented

Resolving this issue as a Duplicate since it has been superseded by #18571.