Provide a way for an ApplicationContextInitializer to access the current test class in the TestContext framework

[stolsvik]

(Not entirely sure this is a lacking feature, but I have not found it yet!)

It seems like when you're within a ApplicationContextInitializer (specified by @ContextConfiguration), you have no way of knowing which test class is being configured. That would have been nice wrt. reading annotation parameters.

Maybe a ThreadLocal hack, whereby the thread class / instance in question was available while the ApplicationContextInitializers was run, and could be accessed via a static method?

[sbrannen]

It seems like when you're within a ApplicationContextInitializer (specified by @ContextConfiguration), you have no way of knowing which test class is being configured.

That's correct. The ApplicationContextInitializer API is defined in the spring-context module and therefore has no direct connection to Spring's testing support in the spring-test module. Consequently, it is not possible to provide access to the test class in an ApplicationContextInitializer.

Maybe a ThreadLocal hack, whereby the thread class / instance in question was available while the ApplicationContextInitializers was run, and could be accessed via a static method?

I am not in favor of introducing any hacks based on a ThreadLocal variable, since the same ApplicationContextInitializer implementation might be configured for multiple test classes within a test suite, and there is no tie between the ApplicationContextInitializer and the test class with regard to the context cache key.

If you wish to modify the ApplicationContext (based on annotations present on a given test class) before it has been refreshed, we recommend that you implement a ContextCustomizerFactory and ContextCustomizer which are designed for use cases like that.

In light of the above, I am closing this issue, but if you have any follow up questions, feel free to post them here.

[stolsvik]

On the face of it, the ContextCustomizer sounds exactly what I would want!

However, this JavaDoc line seems to suggest that it can only be used by adding such references to META-INF?
"By default, the Spring TestContext Framework will use the SpringFactoriesLoader mechanism for loading factories configured in all META-INF/spring.factories files on the classpath."

.. it is not possible to use annotations for this instead? Like some @EnableSuperLibraryTest(stash = true) annotation that pimped out ones Spring test context with the beans that one probably would need when testing the SuperLibrary in stash-mode, but also could look into the context to see if anything should not be created, or should be overridden.

[sbrannen]

On the face of it, the ContextCustomizer sounds exactly what I would want!

👍

However, this JavaDoc line seems to suggest that it can only be used by adding such references to META-INF?
"By default, the Spring TestContext Framework will use the SpringFactoriesLoader mechanism for loading factories configured in all META-INF/spring.factories files on the classpath."

That's correct. A ContextCustomizerFactory must be registered via spring.factories.

The reason is that ContextCustomizer is more of an SPI (implemented by frameworks) than an API (implemented by developers writing tests).

.. it is not possible to use annotations for this instead? Like some @EnableSuperLibraryTest(stash = true) annotation that pimped out ones Spring test context with the beans that one probably would need when testing the SuperLibrary in stash-mode, but also could look into the context to see if anything should not be created, or should be overridden.

It should be possible to provide support for registering a ContextCustomizer declaratively via an annotation on a test class, but that is a separate topic. Feel free to open a new issue if you would like to discuss that further.

[stolsvik]

I felt free! #26148