Issue 1:
Sam Brannen opened SPR-7960 and commented

Overview

Spring 3.1 introduces support for bean definition profiles, such as 'production', 'dev', etc.

The Spring TestContext framework should be extended to support declarative configuration of bean definition profiles on a per-ApplicationContext basis.

One option would be to provide an attribute in the @ContextConfiguration annotation to allow the spring.profiles.active value to be set declaratively.

Further Resources

Comment on SpringSource blog

Example Tests Using @ActiveProfiles

The following examples -- which are taken from the Spring test suite -- show how to declare which active profiles to use when loading an application context via the new @ActiveProfiles annotation.

Testing Active Profiles with @Configuration Classes

\

DefaultProfileConfig: @Configuration class without a @Profile declaration

DevProfileConfig: @Configuration class with a @Profile("dev") declaration

DefaultProfileAnnotationConfigTests: JUnit 4 test that instructs the TestContext framework to load an application context from both the DefaultProfileConfig and DevProfileConfig @Configuration classes

DevProfileAnnotationConfigTests: extends DefaultProfileAnnotationConfigTests and instructs the TestContext framework to activate the "dev" profile via @ActiveProfiles("dev")

Note that the autowired employee is null in DefaultProfileAnnotationConfigTests but not null in DevProfileAnnotationConfigTests; whereas, the pet is non-null for both the default and dev profile.

@Configuration
public class DefaultProfileConfig {

@Bean
public Pet pet() {
return new Pet("Fido");
}
}

\

@Profile("dev")
@Configuration
public class DevProfileConfig {

@Bean
public Employee employee() {
Employee employee = new Employee();
employee.setName("John Smith");
employee.setAge(42);
employee.setCompany("Acme Widgets, Inc.");
return employee;
}
}

\

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = { DefaultProfileConfig.class, DevProfileConfig.class },
loader = AnnotationConfigContextLoader.class)
public class DefaultProfileAnnotationConfigTests {

@Autowired
protected Pet pet;

@Autowired(required = false)
protected Employee employee;

@Test
public void pet() {
assertNotNull(pet);
assertEquals("Fido", pet.getName());
}

@Test
public void employee() {
assertNull("employee bean should not be created for the default profile", employee);
}
}

\

@ActiveProfiles("dev")
public class DevProfileAnnotationConfigTests extends DefaultProfileAnnotationConfigTests {

@Test
@Override
public void employee() {
assertNotNull("employee bean should be loaded for the 'dev' profile", employee);
assertEquals("John Smith", employee.getName());
}

}

Testing Active Profiles with XML Configuration

\

The DefaultProfileXmlConfigTests and DevProfileXmlConfigTests classes are analogous to the DefaultProfileAnnotationConfigTests and DevProfileAnnotationConfigTests classes described above. The difference is that both of these test classes use the XML-based configuration found in DefaultProfileXmlConfigTests-context.xml, which combines the declaration of the default and dev profiles in a single XML file. Otherwise, the use of @ActiveProfiles and the behavior of the tests is identical.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.1.xsd">

<bean id="pet" class="org.springframework.beans.Pet">
<constructor-arg value="Fido" />
</bean>

<beans profile="dev">
<bean id="employee" class="org.springframework.beans.Employee">
<property name="name" value="John Smith" />
<property name="age" value="42" />
<property name="company" value="Acme Widgets, Inc." />
</bean>
</beans>

</beans>

\

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class DefaultProfileXmlConfigTests {

@Autowired
protected Pet pet;

@Autowired(required = false)
protected Employee employee;

@Test
public void pet() {
assertNotNull(pet);
assertEquals("Fido", pet.getName());
}

@Test
public void employee() {
assertNull("employee bean should not be created for the default profile", employee);
}
}

\

@ActiveProfiles("dev")
public class DevProfileXmlConfigTests extends DefaultProfileXmlConfigTests {

@Test
@Override
public void employee() {
assertNotNull("employee bean should be loaded for the 'dev' profile", employee);
assertEquals("John Smith", employee.getName());
}

}

Affects: 3.1 M1

Issue Links:

#13033 Introduce SmartContextLoader SPI ("depends on")

#12410 Decide what to do with @IfProfileValue

#10852 Provide TestContext support for @Configuration classes

#9538 Introduce strategy for determining if a profile value is enabled for a particular test environment

5 votes, 6 watchers

Issue 2:
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:

#13625 SystemProfileValueSource is not very compatible with the new 3.1 default system property profiles

#12615 TestContext framework should support declarative configuration of bean definition profiles

#13622 Allow overriding @ActiveProfiles in test classes with system property

#16300 Introduce annotation to skip test based on active Spring profile

6 votes, 7 watchers