Introduce system property to disable context caching in the TestContext framework [SPR-11576]

[spring-projects-issues]

Gary Russell opened SPR-11576 and commented

Currently, when using @ContextConfiguration and SpringJunit4ClassRunner, the context is only close() d (AFTER CLASS) if the class is annotated with @DirtiesContext.

I don't know if this is a change in behavior or has always been this way, but it seems non-intuitive to me, given that the context is no longer available for use.

With "active" contexts (such as Spring Integration) this can cause issues when many tests are run, for example in a gradle build. Aside from the memory/cpu, it can cause unfortunate side effects (such as MBean name collisions, test cross-talk when using the same JMS queue name, etc).

We have started to mark our tests with class-level DirtiesContext but I wonder if this behavior is intentional.

If this would be considered too big a change, perhaps we could consider a system property, e.g. spring.always.close.test.context.after.class ?

---

Affects: 3.0 GA

Issue Links:

• Use soft or weak references for context caching in the TestContext framework [SPR-7687] #12343 Use soft or weak references for context caching in the TestContext framework
• Limit size of context cache in the TestContext framework [SPR-8055] #12710 Limit size of context cache in the TestContext framework

[spring-projects-issues]

Sam Brannen commented

I don't know if this is a change in behavior or has always been this way, but it seems non-intuitive to me, given that the context is no longer available for use.

This is by design and has always been this way. For details, please see the Context caching section of the "Testing" chapter in the reference manual.

It is certainly too big a change to turn off caching, since that is one of the major features of the Spring TestContext Framework; however, introducing a system property to turn it off for a test suite is something that we could consider.

Regards,

Sam

[spring-projects-issues]

Gary Russell commented

Thanks, Sam; I fully understand the caching angle, but I always thought that the scope of the cache was within the class - so the context is cached between test methods.

I had not considered the case where multiple test classes might use the same context; so I fully understand the issue now.

The vast majority of our test cases use the standardized context resource name (class.getSimpleClassname() + "-context.xml" in the same package as the test class), so it's generally not the case where we share contexts across multiple test classes.

The reference doc is also a little misleading... "... that context will be cached and reused for all subsequent tests that declare the same unique context configuration within the same test suite....".

We don't use test suites, but I see later in the doc it says "...To benefit from the caching mechanism, all tests must run within the same process or test suite....".

So you have our case covered there.

Perhaps another thought (in a future release) would be to close the context after the class, only if the @ContextConfiguration has no attributes (using the default naming), but I can see that even that might cause grief for others.

I am fine if you just want to close this as won't fix; we can simply mark all of our classes with @DirtiesContext

[spring-projects-issues]

Sam Brannen commented

Hi Gary,

The reference doc is also a little misleading... "... that context will be cached and reused for all subsequent tests that declare the same unique context configuration within the same test suite....".

We don't use test suites, but I see later in the doc it says "...To benefit from the caching mechanism, all tests must run within the same process or test suite....".

Yeah, maybe we should stop using the term test suite, since that seems to cause confusion for many people. By "suite" we don't mean JUnit "@SuiteClasses" or TestNG's support for "suites" but rather a collection of tests that are executed together -- for example in a Maven build.

So you have our case covered there.

Good. ;)

Perhaps another thought (in a future release) would be to close the context after the class, only if the @ContextConfiguration has no attributes (using the default naming), but I can see that even that might cause grief for others.

No, that unfortunately would not be acceptable either. Keep in mind that most projects (i.e., not frameworks) define a single set of configuration for all tests within a given layer (e.g., repository tests). As a best practice, most projects (should) define an abstract base class that declares the configuration for all test classes for the given layer. So if a base class declares an empty @ContextConfiguration annotation, we would definitely not want to close the context after each concrete subclass completes, since that would potentially increase the build time by an order of magnitude.

Make sense?

I am fine if you just want to close this as won't fix;

I will leave it open for now, since it is related to other issues regarding control of the caching mechanism. I'll link some of those to this issue now.

we can simply mark all of our classes with @DirtiesContext

OK. That's what I would recommend for your use case. ;)

Cheers,

Sam

[spring-projects-issues]

Sam Brannen commented

This issue is related to #12710 and #12343.

[spring-projects-issues]

Sam Brannen commented

Resolving this issue as "Won't Fix" since:

• Use soft or weak references for context caching in the TestContext framework [SPR-7687] #12343 has been resolved: now caching using soft references
• Introduce BEFORE_METHOD and BEFORE_CLASS modes for @DirtiesContext [SPR-12429] #17035 has been resolved: adding support for BEFORE_METHOD, BEFORE_CLASS, and BEFORE_EACH_TEST_METHOD modes to @DirtiesContext

[spring-projects-issues]

Sam Brannen commented

Update: in case you're interested, #12343 has been superseded by #12710.