Decide what to do with `@IfProfileValue` [SPR-7754]

[spring-projects-issues]

Dave Syer opened SPR-7754 and commented

Now that @Profile (and "profile" generally) has a meaning in the framework, the old test support for detecting system properties looks like it has an awkward name. In Spring 3.1 terms, what @IfProfileValue does is detect key-value pairs in the Environment (not profiles).

One simple thing we should definitely do is add a ProfileValueSource that can pull values from the Environment.

More radically, maybe we could rename @IfProfileValue(name=,value=) to @Environment(key=,value=).

Another suggestion is that we could provide a way to activate profiles declaratively for tests or test classes. Something I've been playing with is this (new components ProfileSuite and @ActiveProfile):

@RunWith(Suite.class)
@SuiteClasses({ HsqlTest.class, DerbyTest.class })
public class JdbcDaoIntegrationTests {

	@RunWith(ProfileSuite.class)
	@SuiteClasses({ JdbcSearchableJobInstanceDaoTests.class, JdbcSearchableJobExecutionDaoTests.class,
			JdbcSearchableStepExecutionDaoTests.class })
	public static abstract class BaseTest {
	}

	@ActiveProfile("hsql")
	public static class HsqlTest extends BaseTest {
	}

	@ActiveProfile("derby")
	public static class DerbyTest extends BaseTest {
	}

}

It says: run these three test classes twice each, once with profile "hsql" and once with profile "derby". This has the nice feature that @EnvironmentValue can still be honoured inside the individual tests (per method).

---

Issue Links:

• 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
• TestContext framework should support declarative configuration of bean definition profiles [SPR-7960] #12615 TestContext framework should support declarative configuration of bean definition profiles
• Allow overriding @ActiveProfiles in test classes with system property [SPR-8982] #13622 Allow overriding @ActiveProfiles in test classes with system property
• Introduce annotation to disable test based on active Spring profile [SPR-11677] #16300 Introduce annotation to skip test based on active Spring profile

6 votes, 7 watchers

[spring-projects-issues]

Chris Beams commented

Assigning to Sam for comments (and possibly implementation of course).

Sam, if you haven't gotten familiar with the Environment/Profiles support, this is probably a great time to do so.

Dave, with regard to the @Environment annotation, it might be more accurate to think of @Property or @EnvironmentProperty or something to that effect. What's really being evaluated in this situation is properties as accessed through the environment.

It should be noted that @Profile and @IfProfileValue have pretty close semantics already. In the case of @Profile, it indicates a @Component/@Configuration class should loaded only if the profile(s) specified in the value attribute are currently active. In the case of @IfProfileValue, it indicates, that a @Test method should be executed only if the key/value (property) is present and matching.

I'm not sure how widely used @IfProfileValue is right now. It would be nice to consider some kind of unification of semantics in any case.

[spring-projects-issues]

Dave Syer commented

A more radical idea would be to remove @IfProfileValue and replace it with @Profile. This means re-thinking Environment a little so we can avoid the "special" key name ("springProfiles" is a key name in the Environment which is special because it switches on profiles). We can do that by sticking to the old @IfProfileValue style definition of a profile value (it has to be explicit about its key name), so you would just have Environment with key-value pairs, and none of them would have any special status. @Profile (and similar feature in XML) would need to name the key as well as the value(s), just like @IfProfileValue does now, and then the latter could be simply removed in favour of the former.

[spring-projects-issues]

Helena Edelson commented

I like the move to @Profile idea and have been starting to play around with an environment module that in part leverages the Sigar jar to detect environment data, explicitly filtered via Spring.

[spring-projects-issues]

Dave Syer commented

Another suggestion: an environment matcher utility so that you can use imperative instead of declarative approach to skipping tests by profile. E.g. somethng like this

@Test
public void shouldOnlyWorkWithOracle() {
	assumeTrue(TestEnvironmentUtils.activeProfiles().contains("oracle"));
	...
}

I guess TestEnvironmentUtils would need to access the ApplicationContext and extract the environment (so maybe it would have to be a field in the test case). With this approach a user has access to all the profile and property information (name=value pairs) in the Environment.

The inverse

[spring-projects-issues]

Neale Upstone commented

A thought to feed in here...

Just working with a number of Spring 3 based tests at the moment, and we have un-DRY things like:

@IfProfileValue(name = "test_category", values = { "all", "integration-test" })
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:/integration-test.xml" })
public class SomeIntegrationTest {
    ...
}

What's missing is the Stereotype support that we have for components.

I'd like all Spring annotations to be able to be targetted to an annotation type so that I can just have:

@RunWith(SpringJUnit4ClassRunner.class)
@IntegrationTest
public class SomeIntegrationTest {
    ...
}

with the @ContextConfiguration and @IfProfileValue on our @IntegrationTest annotation definition.

[spring-projects-issues]

Sam Brannen commented

@Neale: I've captured your comments in a new JIRA issue: #12483

Cheers,

Sam

[spring-projects-issues]

Caleb Cushing commented

deprecate the original annotation. I would like something either based on PropertySourceMerger which I believe can merge properties, the environment etc, and/or support SpEL for disabling tests. As it stands I've realized that @IfProfileValue isn't actually valuable to me.