Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-issuemaster opened this issue Mar 18, 2014 · 6 comments

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Mar 18, 2014

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:

  • #12343 Use soft or weak references for context caching in the TestContext framework
  • #12710 Limit size of context cache in the TestContext framework
@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 18, 2014

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-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 18, 2014

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-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 19, 2014

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-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 19, 2014

Sam Brannen commented

This issue is related to #12710 and #12343.

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Apr 18, 2015

Sam Brannen commented

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

  • #12343 has been resolved: now caching using soft references
  • #17035 has been resolved: adding support for BEFORE_METHOD, BEFORE_CLASS, and BEFORE_EACH_TEST_METHOD modes to @DirtiesContext
@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Apr 19, 2015

Sam Brannen commented

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.