I am seeing side-effects in an integration test that initializes a Spring ApplicationContext using @ContextConfiguration. Specifically, close() on the context does not appear to be being called, ever. I noticed this because one of my DispoableBeans is not receiving a destroy() callback and that is what is causing the side-effect [which pops up when a @Test runs in another, unrelated TestCase class].
I understand a test ApplicationContext is cached between test methods, but I would still expect the context to be closed after all tests have run, before moving on to the next test class in the suite.
Improvement
Resolved
Major
ApplicationContext not closed when using @ContextConfiguration to implement integration tests
Some information from Colin Sampaleanu on this:
–
Keith, unfortunately it's not at all clear to me that there should be any expectation that the should have close() called on it by default.
With the old AbstractDependencyInjectionSpringContextTests, the same app context was shared across all the test cases (that used the same context path(s)), and close was only called at the end of the test run, and there was a clear contract here to the extent that the two levels higher superclass of that explicitly mentions that close on the cached context(s) is done via a JVM shutdown hook and therefore woudl only happen when the entire test suite is done.
As for the new TestContext based code, the "contract" is a little bit greyer, but the docs
http://static.springframework.org/spring/docs/2.5.x/reference/testing.html#testcontext-framework
specifically mention the caching, and talk about the fact that a test method may dirty the context, and need to be annotated with @DirtiesContext, so that basically implies that close() would never be called otherwise.
What is probably needed is an annotation that can be applied to the whole class, which says to reload the context after this entire test case, but not after each method...