spring.profiles.active is not honored when building the context cache key in the TestContext framework [SPR-11135]

[spring-projects-issues]

Jeroen Benckhuijsen opened SPR-11135 and commented

Status Quo

The Spring TestContext Framework has a mechanism for caching loaded application contexts. This cache mechanism works by inspecting a number of attributes of the @ContextConfiguration, @WebAppConfiguration, and @ActiveProfiles annotations.

Claim

The aforementioned caching mechanism does not honor the spring.profiles.active system property in case it is set, although the started application context does.

In case two or more tests are run with different @ActiveProfiles configurations, the application contexts loaded for those tests are viewed as distinct application contexts, although the resulting contexts are equal, making the caching mechanism ineffective.

---

Affects: 3.2.5

Attachments:

• pom.xml (2.99 kB)
• spr11135.zip (7.20 kB)

Issue Links:

• Allow overriding @ActiveProfiles in test classes with system property [SPR-8982] #13622 Allow overriding @ActiveProfiles in test classes with system property

[spring-projects-issues]

Sam Brannen commented

Hi Jeroen Benckhuijsen,

You claim that the caching mechanism in the TestContext framework does not honor the spring.profiles.active system property, but that the started application context does.

By design, the Spring TestContext Framework has never supported the spring.profiles.active system property in conjunction with @ActiveProfiles. So this is not a bug per se.

When you say "the started application context does", do you mean that an application context that is loaded outside the testing framework would have the system property honored? If so, that is correct and also by design.

Or... did you mean something else?

In case two or more tests are run with different @ActiveProfiles configurations, the application contexts loaded for those tests are viewed as distinct application contexts, although the resulting contexts are equal, making the caching mechanism ineffective.

Again, this is by design: if two test classes are configured identically via @ContextConfiguration and optionally @WebAppConfiguration but differently via @ActiveProfiles, they do in fact reference two distinct application contexts which will be cached separately.

I am therefore inclined to resolve this issue as Works as Designed, but if you can submit a code example that demonstrates your claim that "the resulting contexts are equal" that would in fact be a bug, and I would be happy to look into it further.

Consult the README for details on how to contribute self-contained projects reproducing issues.

Thanks,

Sam

[spring-projects-issues]

Sam Brannen commented

Waiting on feedback from the reporter of this issue.

[spring-projects-issues]

Jeroen Benckhuijsen commented

Hi Sam,

Thanks for the info. Just a short explanation of the issue I'm facing, I'll post a code example later on.

We have generic tests which load our application context. The context has various profiles with beans defined, e.g.

<beans profile="p1">
    <bean id="bean1" class="...BeanProfile1"/>
</beans>
<beans profile="p2">
    <bean id="bean1" class="...BeanProfile2"/>
</beans>

our test is defined as:

@RunWith...
@ActiveProfiles("p1")
public class ...GenericTest {

}

@RunWith...
@ActiveProfiles("p1")
public class ...P1SpecificTest {

}

@RunWith...
@ActiveProfiles("p2")
public class ...P2SpecificTest {

}

The two specific tests are in two different source folders, which are excluded from the build using Maven profiles, i.e. only one of them is active based on the selected profile.

The @ActiveProfiles setting is used as a default, to allow easy execution from Eclipse btw. From Maven, we run the tests, with -Dspring.profiles.active=... as command line arguments

• When running with -Dspring.profiles.active=p1, tests behave as expected: BeanProfile1 is created at runtime and the application context is only loaded once. Both the GenericTest and the P1SpecificTest are executed
• When running with -Dspring.profiles.active=2: BeanProfile2 is created at runtime (i.e. P2 is active as profile), both for the GenericTest and the P2SpecificTest. However, the application context is loaded twice: one with (according tot he Spring JUnit runner) P1 active, one with P2 active, although both have an active profile P2.

Hope this helps..

[spring-projects-issues]

Jeroen Benckhuijsen commented

Attached a testcase with the desired behaviour

[spring-projects-issues]

Sam Brannen commented

Note that this issue is related to #13622.

[spring-projects-issues]

Sam Brannen commented

Attached updated pom.xml file with proper configuration for all three executions.

[spring-projects-issues]

Sam Brannen commented

Hi,

I took a deeper look into this based on your attachment.

However, there's actually an issue with your Maven configuration. Specifically, you have not configured the executions correctly. See the following comment on Stack Overflow for details: http://stackoverflow.com/a/7195552/388980

After I fixed this issue (see attached, updated pom.xml), I investigated further and discovered that everything works as I would expect. The key here is that the Spring TestContext Framework (TCF) does not honor the spring.profiles.active system property. See my comments above as well as the discussions in #13622.

Regards,

Sam

[spring-projects-issues]

Sam Brannen commented

Resolving this issue as Works as Designed.

Please see the discussion in the comments.

For discussions related to honoring the spring.profiles.active in general (i.e., by allowing the system property to override configuration via @ActiveProfiles), please refer to #13622.