Unit Tests Pass Singly and Fail When Run Together

[danielkwinsor]

Hi,
I'm using spring 3.1.2 and using maven 3.0.4 from the command line and from Eclipse's m2e plugin. I have some tests that will pass if the test is run singly, as in "mvn clean test -Dtest=com.company.neo.spring.view.NeoXsltViewResol verTest -e" However, when run alongside all the other unit tests, as in "mvn clean install -e" then this test will be in error.

In the particular case of NeoXsltViewResolverTest it is in error because the context is org.springframework.context.support.GenericApplica tionContext but the NeoXsltView gets the context and casts it to NeoXmlWebApplicationContext (extends from XmlWebApplicationContext)

java.lang.ClassCastException: org.springframework.context.support.GenericApplicationContext cannot be cast to com.company.neo.spring.context.NeoXmlWebApplicationContext
        at com.company.neo.spring.view.NeoXsltView.getStylesheetSource(NeoXsltView.java:69)
        at org.springframework.web.servlet.view.xslt.XsltView.loadTemplates(XsltView.java:417)
        at org.springframework.web.servlet.view.xslt.XsltView.initApplicationContext(XsltView.java:181)
        at org.springframework.context.support.ApplicationObjectSupport.initApplicationContext(ApplicationObjectSupport.java:119)
        at org.springframework.web.context.support.WebApplicationObjectSupport.initApplicationContext(WebApplicationObjectSupport.java:72)

XsltView extends org.springframework.context.support.ApplicationObj ectSupport, which means its setApplicationContext is final... Thus NeoXsltView cannot override ApplicationContextAware's setApplicationContext method, though it can implement ApplicationContextAware.


This isn't the only test that fails. Another test is harder to diagnose, but when it runs singly it scans certain files, and when run in the test suite it seems to scan extra files. I assume it must be the context has held over from the test that was run just prior, which had probably scanned some other file in its @ContextConfiguration then added some data to an @Autowired bean

Am I operating under false assumptions or is my context not getting cleared out for each unit test?

[danielkwinsor]

Ok found the answer for the second one: A system property was getting set and not cleared in test #1 then causing test #234 to fail. Just curious, why shouldn't all system properties be cleared when a context ends?

I still don't know which test is causing the context problem, though I have discovered and tried @DirtiesContext for all the tests I can see that change the context.

[Sam Brannen]

Am I operating under false assumptions or is my context not getting cleared out for each unit test?

You are definitely operating under false assumptions. The context will not get cleared after each test. In fact, exactly the opposite happens: contexts are cached by default.

Have you ever read the testing chapter of the reference manual?

In any case, I'd recommend you read these sections:

• Context management and caching
• Context caching

Regards,

Sam

[Sam Brannen]

In the particular case of NeoXsltViewResolverTest it is in error because the context is org.springframework.context.support.GenericApplica tionContext but the NeoXsltView gets the context and casts it to NeoXmlWebApplicationContext (extends from XmlWebApplicationContext)

The Spring TestContext Framework historically has not provided support for loading a WebApplicationContext in integration tests.

This support was first introduced in Spring Framework 3.2. See the New Testing Features section of the reference manual for details.

So if your components require a WebApplicationContext, you'll have to upgrade to Spring Framework 3.2 or resort to true unit tests to test the affected components.

Note that using the TestContext framework (i.e., via @ContextConfiguration, etc.) to load your application context is a form of integration testing, not unit testing.

Regards,

Sam

[danielkwinsor]

Thank you, I had not read those particular documents. My contexts were cached separately as each has its own context.xml location in @ContextConfiguration. For the second problem it wasn't even a context problem at all, it was a system property problem.

Still, if it is as you say that Spring Framework 3.1.2 does not support WebApplicationContexts, then I do not understand why the test would pass when run singly. I will have to look into 3.2 further, see if that fixes the issue.