Support for @DirtiesContext at the test class level [SPR-4702]

[spring-projects-issues]

Noel Flicken opened SPR-4702 and commented

Expected behavior:
Context should be close()'d after end of test class execution

Observed behavior:
Context only closed when @DirtiesContext annotates method

Multiple test classes can re-use the same context, which allows for faster test execution, so automatically closing a context after test class execution is probably not the best mechanism.

However, there should be a way to annotate that a context should be close()'d after all tests in a test class are executed.

Suggested fix:

• allow @DirtiesContext to annotate class
• add TestExecutionListener#destroyTestInstance

Willing to implementing, if given approval of design.

---

Issue Links:

• ApplicationContext not closed when using @ContextConfiguration to implement integration tests [SPR-5395] #10068 ApplicationContext not closed when using @ContextConfiguration to implement integration tests ("is duplicated by")
• Add a setDirty method to AbstractTestNGSpringContextTests [SPR-5305] #9978 Add a setDirty method to AbstractTestNGSpringContextTests
• Reload the application context for each test in a class with a class level annotation [SPR-5640] #10311 Reload the application context for each test in a class with a class level annotation
• ANT does not call destroy-method after tests [SPR-2007] #6700 ANT does not call destroy-method after tests
• ApplicationContext not closed when using @ContextConfiguration to implement integration tests [SPR-5395] #10068 ApplicationContext not closed when using @ContextConfiguration to implement integration tests

Referenced from: commits 2dee54b, e77e070, 7782184, 0483cb5, 8dec6af, 1f087b4, 51b8b99, f26e2e3

4 votes, 6 watchers

[spring-projects-issues]

Noel Flicken commented

This issue differs from #6700 in expected implementation. SPR_2007 is difficult to implement due to JUnit architectural limitations.

This issue suggests a feature to optionally allow a context to be automatically closed after all test methods in a given Test Class are run, i.e. when JUnit @AfterClass methods are run.

[spring-projects-issues]

Juergen Hoeller commented

OK, good point - although I'm not entirely clear how exactly such @AfterClass closing will fit with context sharing. We'll see.

Juergen

[spring-projects-issues]

Noel Flicken commented

Fair enough. Allowing @DirtiesContext to annotate a test class has a clear semantic meaning, and is a natural extension to its currently method-only usage. This means that the interaction between @DirtiesContext and context-sharing would be unchanged from the current implementation.

[spring-projects-issues]

Eric Jain commented

This would also be beneficial for TestNG tests (e.g. using AbstractTestNGSpringContextTests) where one would like to make use of TestNG's support for explicit dependencies between test methods. Not being able to control context reloading at the class level makes this feature a lot less useful (and the functional tests a lot uglier).

[spring-projects-issues]

Olaf Otto commented

I would also like a convenient way to enforce context destruction after test class execution. In my specific case, I have observed that the refresh() that takes place on test class execution creates a seemingly new context but does not dispose old singletons (those are destroyed after all test classes have finished or if an exception is thrown...) which causes a significant memory consumption...

[spring-projects-issues]

Joost den Boer commented

Destroying the context would be very welcome. I have several testcases with multiple testmethods which, when using @DirtiesContext on method level, cause test failures because when creating a new context for the last testmethods no new db2 connections can be made. Apparently a problem with our db2 servers which cannot handle setting up and destroying connections so fast. Destroying the whole context would be a great solution for this problem.

I tried to work around it by creating a @DirtiesBean annotation which just destroys the one bean I had used in the test. It seemed to work fine but I now run into different destroy behaviour between running in Maven and in Eclipse. (See http://forum.springsource.org/showthread.php?p=240436#post240436)

[spring-projects-issues]

Sam Brannen commented

@DirtiesContext is now supported at the class level as well as at the method level.

This is made possible via new support for 'before class' and 'after class' callbacks in the TestExecutionListener interface. DirtiesContextTestExecutionListener now implements afterTestClass(TestContext) which provides the class-level support for @DirtiesContext.

[spring-projects-issues]

Sam Brannen commented

Note: due to the limitations of JUnit 3.8, @DirtiesContext is not supported at the class level for tests run with subclasses of AbstractJUnit38SpringContextTests.

[spring-projects-issues]

Sam Brannen commented

Noel, Eric, Olaf, Joost, et al,

Please try out this new functionality in one of the upcoming nightly snapshots or in 3.0.0.RC1, and let me know if this meets your needs. Note that using @DirtiesContext at the class level should be fully supported in JUnit 4.6 and TestNG 5.9.

Thanks for all of your input!

Sam