Very similar to issue #26141, I find that ContextConfiguration should be able to append to an existing ContextConfiguration. But this seems to not be possible.
This is unfortunate as the ContextConfiguration can be used as a meta-annotation. I've tried to make some nice bespoke annotations that can be used in our shop that can be slapped on the test case - but that fails if the test also includes a \@ContextConfiguration annotation - or a second bespoke annotation that also needs to add itself as a ContextConfiguration.
This "only one" seems like this also holds even if the first specifies initializers, and the other classes.
(What actually still works, though, is the feature where any inner static classes annotated with Configuration is automatically picked up without ContextConfiguration pointing to it: This still works if initializers is specified, but not if classes is specified. The latter seems strange; Would it not be nice if I could point to existing app Configuration classes using the @ContextConfiguration, and then include some test-specific Configuration classes as inner classes without having to also include those in the classes-list?)
Maybe a parameter "append=true" would suffice here?
Comment From: sbrannen
Thanks for raising the issue.
I have created #26145 which is a similar request for @ActiveProfiles, and we will consider this in conjunction with that issue.
Comment From: stolsvik
@sbrannen As with my comment on #26141, I am not sure I agree to the title change? Or, I might not understand what you mean by "local".
For my part, I wish the test framework would "collate" all @ContextConfigurations in the scope of the test.
Specifically, I would like to use the @ContextConfiguration as a meta-annotation on an annotation @MatsSimpleTestContext which sets up a standard set of beans often needed in testing, for my "Mats" library. The problem is if the test-class also specifies ContextConfiguration, then my annotation's wishes simply vanishes.
I find such an annotation much nicer and succinct than explaining that you must either include MatsTestInfrastructureConfiguration in your list of configuration classes, or place an \@Import annotation on an inner static \@Configuration class. All other such Components and Configurations you import probably relate to your actual application - this Mats-library-specific Configuration class looks out of place in such a list; Much nicer then with a direct "enable"-style library-specific annotation.
As mentioned, an extra property "append=true" or something could be used to point out that such collating was the desired operation.
Comment From: sbrannen
Since the community has not displayed significant interest in this feature during the last 1.5 years, the team has decided to close this issue.
However, if the community displays increased interest in this feature we would be willing to reconsider.
Comment From: stolsvik
I find this sad - I believe this is one of those issues where devs end up with "oh, that doesn't work - we'll have to hack our way around it then", typically after hours of head-scratching.
It seems like the feature would be pretty straight-forward to implement, as similar features evidently exists which do handle the \@TestPropertySource, ref. #23299. It would close a very annoying, and obvious when you hit it, limitation with the framework.
Comment From: stolsvik
It also seems like #26141, #26142, and #26145 would be fixed in an identical manner - I am certain that the combined annoyance with these deficiencies are pretty substantial if you were able to sum it up.