Spring integration tests with profile

Question

In our Spring web applications, we use the Spring bean profiles to differentiate three scenarios: development, integration, and production. We use them to connect to different databases or set other constants.

Using Spring bean profiles works very well for the changing the web app environment.

The problem we have is when our integration test code needs change for the environment. In these cases, the integration test loads the application context of the web app. This way we don't have to redefine database connections, constants, etc. (applying the DRY principle).

We setup our integration tests like the following.

@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = ["classpath:applicationContext.xml"]) public class MyTestIT {    @Autowired    @Qualifier("myRemoteURL")  // a value from the web-app's applicationContext.xml    private String remoteURL;    ...  } 

I can make it run locally using @ActiveProfiles, but this is hard-coded and causes our tests to fail on the build server.

@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = ["classpath:applicationContext.xml"]) @ActiveProfiles("development") public class MyTestIT { ... } 

I also tried using the @WebAppConfiguration hoping that it might somehow import the spring.profiles.active property from Maven, but that does not work.

One other note, we also need to configure our code so that developers can run the web app and then run the tests using IntelliJ's test runner (or another IDE). This is much easier for debugging integration tests.

Answer 1

As other people have already pointed out, you can opt to use Maven to set the spring.profiles.active system property, making sure not to use @ActiveProfiles, but that's not convenient for tests run within the IDE.

For a programmatic means to set the active profiles, you have a few options.

1. Spring 3.1: write a custom ContextLoader that prepares the context by setting active profiles in the context's Environment.
2. Spring 3.2: a custom ContextLoader remains an option, but a better choice is to implement an ApplicationContextInitializer and configure it via the initializers attribute of @ContextConfiguration. Your custom initializer can configure the Environment by programmatically setting the active profiles.
3. Spring 4.0: the aforementioned options still exist; however, as of Spring Framework 4.0 there is a new dedicated ActiveProfilesResolver API exactly for this purpose: to programmatically determine the set of active profiles to use in a test. An ActiveProfilesResolver can be registered via the resolver attribute of @ActiveProfiles.

Regards,

Sam (author of the Spring TestContext Framework)