All tests using SpringJUnit4Runner fail

[Jesse Domack]

I have a project that uses SpringJUnit4Runner to test our Controllers and Filters. When running these particular tests under eclipse, I get the following exception:

 

java.lang.IllegalStateException: Failed to load ApplicationContext
        at org.springframework.test.context.CacheAwareContextLoaderDelegate.loadContext(CacheAwareContextLoaderDelegate.java:99)
        at org
11:53:55 PM PIT >> FINE : SLAVE : .springframework.test.context.DefaultTestContext.getApplicationContext(DefaultTestContext.java:101)
        at org.springframework.test.context.web.ServletTestExecutionListener.setUpRequestContextIfNecessary(ServletTestExecutionListener.java:155)
        at org.springfr
11:53:55 PM PIT >> FINE : SLAVE : amework.test.context.web.ServletTestExecutionListener.prepareTestInstance(ServletTestExecutionListener.java:100)
        at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:319)
        at org.springframework.test.context.j
11:53:55 PM PIT >> FINE : SLAVE : unit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:212)
        at org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
        at org.junit.internal.runners.model.ReflectiveCallable.run
11:53:55 PM PIT >> FINE : SLAVE : (ReflectiveCallable.java:12)
        at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
        at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:232)
        a
11:53:55 PM PIT >> FINE : SLAVE : t org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:89)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
        at org.junit.ru
11:53:55 PM PIT >> FINE : SLAVE : nners.ParentRunner.runChildren(ParentRunner.java:236)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
        at org.springframework.test.context.junit4.statements.RunBeforeT
11:53:55 PM PIT >> FINE : SLAVE : estClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
        at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
        at
11:53:55 PM PIT >> FINE : SLAVE :  org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:175)
        at org.pitest.junit.adapter.CustomRunnerExecutor.run(CustomRunnerExecutor.java:42)
        at org.pitest.junit.adapter.AdaptedJUnitTestUnit.execute(AdaptedJUni
11:53:55 PM PIT >> FINE : SLAVE : tTestUnit.java:85)
        at org.pitest.coverage.execute.CoverageDecorator.execute(CoverageDecorator.java:50)
        at org.pitest.execute.containers.UnContainer.submit(UnContainer.java:45)
        at org.pitest.execute.Pitest$3.run(Pitest.java:182)
        at java.lang.Thread.run(
11:53:55 PM PIT >> FINE : SLAVE : Thread.java:662)
Caused by: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Only one AsyncAnnotationBeanPostProcessor may exist within the context.

Has anyone run into this type of issue before, or even tried to run Spring MVC tests with PIT? Any help would be greatly appreciated.

[henry]

On Sunday, 7 September 2014 15:27:07 UTC+1, Jesse Domack wrote:
 

Has anyone run into this type of issue before, or even tried to run Spring MVC tests with PIT? Any help would be greatly appreciated.

I've run PIT on spring projects using the SpringJUnit4Runner without any issues. I tend to exclude some of the tests using MockMvc as they are slow + prone to order dependencies if they pull in in-memory databases, but they ought to work.

Are you able to put together a minimal project that recreates the issue? My best guess from the stack trace you posted is that this is some sort of classpath issue.

Henry

[Jesse Domack]

On Monday, September 8, 2014 4:43:03 AM UTC-5, henry wrote:

 

Are you able to put together a minimal project that recreates the issue? My best guess from the stack trace you posted is that this is some sort of classpath issue.

Yes, I have been able to create another project structured the same way that also has the same problems. It definitely appears classpath related. We have our applicationContext.xmls located in src/main/resources, and this works great when running the junits in eclipse, or launching the server. However, we had to manually configure <testResources> to copy those files to get JUnits to run in maven. While that works, once we try to run the same project under PIT, now it appears that PIT is seeing two sets of applicationContexts (one in target/classes and one in target/test-classes) and it is attempting to load both of them. (Note: they are being referenced in the tests with "classpath:**/META-INF/applicationContext*.xml" ).

If you need further info, I can post the files from the sample project I created that has the same issues.

Thanks, 

Jesse

[Jarkko Rantavuori]

Hi,

can you post a sample project having the issue, not just the files, to somewhere like github?

Manually configuring "testResources" does sound suspicious though. With Spring junit tests that shouldn't be ever needed - I've never done that with my Spring unit tests.

Br,

-Jarkko

--
You received this message because you are subscribed to the Google Groups "PIT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pitusers+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Phil Glover]

HI Jesse,

Can you confirm if this is an issue you observe only in Eclipse or do you get the same result using maven / ant plugin?

Kind Regards,

Phil

[Jesse Domack]

Hi Phil,

This is only an issue when running PIT via Maven (either command line or using m2eclipse). Standard JUnit and non-PIT runs in Eclipse are fine (haven't tried pitclipse plugin). 

[Jesse Domack]

Hi Jarkko,

I have posted a sample project on GIthub here.

Thanks,

Jesse

[Jarkko Rantavuori]

Hi,

I tested the given example project, and I get

> mvn -Ppitest clean verify

- Statistics

================================================================================

>> Generated 4 mutations Killed 2 (50%)

>> Ran 3 tests (0.75 tests per mutation)

================================================================================

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 15.132s

[INFO] Finished at: Wed Sep 10 13:23:53 EEST 2014

[INFO] Final Memory: 10M/25M

[INFO] ------------------------------------------------------------------------

Also, if I use mutationCoverage goal directly, I get the same result:

> mvn org.pitest:pitest-maven:mutationCoverage

...

- Statistics

================================================================================

>> Generated 4 mutations Killed 2 (50%)

>> Ran 3 tests (0.75 tests per mutation)

================================================================================

...

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 8.087s

[INFO] Finished at: Wed Sep 10 13:19:06 EEST 2014

[INFO] Final Memory: 5M/15M

[INFO] ------------------------------------------------------------------------

You're using an old version of pit plugin (0.30 is not the latest), but still, I wasn't able to see the issue.

Br,

-Jarkko

[Jesse Domack]

Hmm... it appears that I committed the code after I "fixed" it. The problem is that we wanted to refer to the applicationContexts using "classpath:" not "file:". I have reverted the code back to use "classpath:" but for some strange reason, now it appears to be running correctly. I'm kind of at a loss, since I know it was throwing errors before.