Allow overriding `@ActiveProfiles` in test classes with system property [SPR-8982]

[spring-projects-issues]

Alex opened SPR-8982 and commented

Status Quo

Support for setting the active bean definition profiles in an integration test within the Spring TestContext Framework (TCF) is currently limited to one of the following techniques:

1. Providing a hard-coded list of profiles declared via the value or profiles attribute of @ActiveProfiles - since Spring Framework 3.1
2. Specifying a custom ActiveProfilesResolver (which programmatically determines the active profiles) declared via the resolver attribute of @ActiveProfiles - since Spring Framework 4.0

In stand-alone or production code, Spring honors the spring.profiles.active system property for determining the set of active profiles to use when loading an ApplicationContext; however, the TCF ignores this system property, relying solely on configuration via @ActiveProfiles.

---

Proposals

1. Provide the ability to override @ActiveProfiles specified in an integration test via the spring.profiles.active system property or some other system property specific to the TCF.
2. Set the spring.profiles.active system property to the value specified via @ActiveProfiles
   • See comments in this issue for background.
   • This point likely warrants its own JIRA issue for proper consideration.

---

Implementation Notes

• Consider introducing a new boolean flag in @ActiveProfiles that allows profiles declared via the annotation to be overridden by those defined via the spring.profiles.active system property (if it is present).

---

Further Resources

Related discussions at Stack Overflow:

• Spring integration tests with profile
• Defining a spring active profile within a test use case
• @ActiveProfiles value is not being assigned to config

---

Affects: 3.1 GA

Issue Links:

• Decide what to do with @IfProfileValue [SPR-7754] #12410 Decide what to do with @IfProfileValue
• Introduce strategy for determining if a profile value is enabled for a particular test environment [SPR-4862] #9538 Introduce strategy for determining if a profile value is enabled for a particular test environment
• SystemProfileValueSource is not very compatible with the new 3.1 default system property profiles [SPR-8985] #13625 SystemProfileValueSource is not very compatible with the new 3.1 default system property profiles
• Introduce annotation to disable test based on active Spring profile [SPR-11677] #16300 Introduce annotation to skip test based on active Spring profile
• spring.profiles.active is not honored when building the context cache key in the TestContext framework [SPR-11135] #15761 spring.profiles.active is not honored when building the context cache key in the TestContext framework

19 votes, 24 watchers

[spring-projects-issues]

Peter De Winter commented

That or it should set the property spring.profiles.active.

[spring-projects-issues]

Sam Brannen commented

Peter De Winter, what do you mean by it?

[spring-projects-issues]

Peter De Winter commented

When running tests with a certain active profile the environment property spring.profiles.active is not being set.

Using ${spring.profiles.active} placeholders inside your XML namespace application context this placeholder is not resolved when launching tests with @ActiveProfiles.

Example:

<context:property-placeholder
            ignore-resource-not-found="false" ignore-unresolvable="false"
            location="classpath:/properties/${spring.profiles.active:test}/external.properties"/>

Now that I read the issue description again it might be this is not completely same request, but the issue reason might be the same...

[spring-projects-issues]

Martin Flower commented

I would also like the @ActiveProfiles annotation to set the value of spring.profiles.active. This will enable me to write

@Configuration
@PropertySource({"classpath:props/configuration.properties","classpath:props/${spring.profiles.active}/configuration.properties"})
public class AppConfigProperties {
...

And my integration tests will inherit from a parent class annotated with @ActiveProfiles("integrationtest") and will pick up an AppConfigProperties which is configured using props/integrationtest/configuration.properties.

At the moment I cannot see how to set spring.profiles.active from the integration test base class (extends AbstractTransactionalTestNGSpringContextTests) as the ApplicationContext seems to be loaded before I can call any processing.

[spring-projects-issues]

Sam Brannen commented

Martin Flower,

At the moment I cannot see how to set spring.profiles.active from the integration test base class (extends AbstractTransactionalTestNGSpringContextTests) as the ApplicationContext seems to be loaded before I can call any processing.

If you need to set the spring.profiles.active system property before the TestContext framework loads your ApplicationContext, you could always do so in a before class method. With TestNG, this would be in an @BeforeClass method, and you could likely achieve the same with an @BeforeSuite or @BeforeTest method.

Regards,

Sam

[spring-projects-issues]

Martin Flower commented

Thanks Sam. At the moment I have the following abstract base classes

@ContextConfiguration(locations = {"/test-context.xml",
		                           "/test-db-context.xml",
		                           "/test-security-context.xml"})
public abstract class AbstractUnitTestWithDB extends AbstractTransactionalTestNGSpringContextTests {
    // Unfortunately @ActiveProfiles annotation does not set the environment variable,
    // which is needed by AppConfigProperties
    static {
        // Needs to be called before the Application Context is loaded
        System.setProperty("spring.profiles.active", "unittest");
    }
}

@ContextConfiguration(locations = {"/integration-context.xml",
                                   "/integration-security-context.xml"})
@TransactionConfiguration(defaultRollback = false)
public abstract class AbstractIntegrationTestWithDB extends AbstractTransactionalTestNGSpringContextTests {
    static {
        // Needs to be called before the Application Context is loaded
        System.setProperty("spring.profiles.active", "integrationtest");
    }
}

So, I'm using a static {} block. My original intention was to use @ActiveProfiles annotation instead, which I couldn't get to work.

Would be putting this code in a @BeforeClass method be an improvement? Maybe ? : )

/Martin

[spring-projects-issues]

Peter De Winter commented

Thanks Sam Brannen. This was indeed a solution to our specific problem.

[spring-projects-issues]

Sam Brannen commented

Martin Flower, if you've already got that code in static blocks, then there isn't really any functional difference between that and using an @BeforeClass method. The only difference is that using an @BeforeClass method might make the intent more obvious. ;)

[spring-projects-issues]

Sam Brannen commented

Peter De Winter, I'm glad that little trick solves your problem!

In fact, it might remain the only way to have the system property set. Even if we implement the original intent of this issue (i.e., allowing the presence of the system property to override @ActiveProfiles), it might be the case that Spring does not set the system property for you. Of course, the details have not yet been decided, but I am leaning toward not setting the system property since that could have adverse side effects on other tests running within the same JVM.

Regards,

Sam

[spring-projects-issues]

Sam Brannen commented

For further ideas on how to set active profiles programmatically, you may be interested in my response to the Spring integration tests with profile thread on Stack Overflow.

[spring-projects-issues]

Grigory Kislin commented

This is the sample of possible fix: http://stackoverflow.com/a/33044283/548473

[spring-projects-issues]

Sam Brannen commented

GKislin, indeed... that's a nice custom work-around.

Thanks for sharing!

[spring-projects-issues]

Wim Deblauwe commented

Voting for this as I have this question: http://stackoverflow.com/questions/41614368

[spring-projects-issues]

Hussein Yapit commented

Spring has been pretty consistent with runtime configuration (like system/env properties) trumping over compile-time config, except for this case. I argue it's a better design to allow systemProperty override @ActiveProfiles by default, i.e. without having to specify a boolean param as suggested in the description.

Alternative proposal includes make DefaultActiveProfilesResolver to be a pass-through if spring.profiles.active has been specified.