Introduce system property to disable context caching in the TestContext framework [SPR-11576] #16200
Currently, when using
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
If this would be considered too big a change, perhaps we could consider a system property, e.g.
Affects: 3.0 GA
The text was updated successfully, but these errors were encountered:
Sam Brannen commented
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.
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
I am fine if you just want to close this as won't fix; we can simply mark all of our classes with
Sam Brannen commented
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 "
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
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.
OK. That's what I would recommend for your use case. ;)