Status Quo

Currently, multiple @ActiveProfiles declarations are discovered within a test class hierarchy (both within the inheritance hierarchy and within the enclosing class hierarchy); however, only one @ActiveProfiles declaration per class is supported, namely the first one found beginning with directly declared annotations and traversing up annotation hierarchies in search of meta-annotations.

Proposal

Initially proposed by @odrotbohm offline, it would be beneficial to support lookups for multiple @ActiveProfiles declarations on a given test class. This would allow one to create custom composed annotations that are meta-annotated with @ActiveProfiles that can be combined on a given test class in an additive fashion.

For example, given the following two composed @ProfileA and @ProfileB annotations...

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@ActiveProfiles("A")
public @interface ProfileA {
}

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@ActiveProfiles("B")
public @interface ProfileB {
}

... ideally one could declare both of those annotations as follows, and Spring would activate both profiles A and B.

@SpringJUnitConfig
@ProfileA
@ProfileB
class MyIntegrationTests {
  // ...
}

Related Issues

• 26142

• 26141

Deliverables

• [ ] Determine if we wish to support multiple local @ActiveProfiles declarations on a given test class.
• [ ] If we decide to support this feature, determine if we wish to introduce a SpringProperties flag to disable the feature in order to support the previous semantics for backwards compatibility.

Comment From: miriSch

Thank you sbrannen, this would definitely be useful! In fact, I could use this feature right now...

Comment From: drekbour

Related SO https://stackoverflow.com/questions/26176038/activeprofiles-in-meta-annotation-and-on-test-class-not-working

This would be very handy (as is the recent work on @TestPropertySource #23299) in making composed annotations to reduce boilerplate in tests.

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.

Comment From: vpavic

FWIW, I too believe this would be very useful and have found myself in the situation attempting to use something similar to the proposal from the opening comment. With the status quo, one has to be mindful of this limitation when composing custom test annotations which is unfortunate especially given how often the annotation composing as a concept is promoted in the community.

Comment From: drekbour

This isn't a killer feature that community is ever going to be all het up about. It's failing of Principle of Least Surprise that will slowly annoy everyone trying to create test utilities for their team. Because it's test code, people will live with hacks/hard-codings but it's a shame to leave such a gap considering the good work on meta-annotation support for several other items. That work actually makes it worse as the expectation is clearly that meta should work since it does for all those other annotations :)

Comment From: teleivo

This would be a great to have. This behavior also surprised me 😬