Seeing IllegalStateException with Infinitest 5.1.103 and STS 2.9.2 and Spring 3.1.1

[bkbonner]

I'm seeing a very similar problem to this: https://github.com/infinitest/infinitest/issues/57.

I'm not sure where the problem is located....but it seems like it's an error with how Infinitest handles the Context. I was hoping someone here might point the Infinitest guys in the right direction.

I've searched the forums here and found this: http://forum.springsource.org/showth...ght=infinitest (but I don't have this problem. the tests run, they just fail incorrectly. If I run the tests manually with JUnit 4.1.10, I get a greenbar.


I end up getting red X's in the Problem view of STS.

I'm running: JDK 1.6, SpringToolSuite 2.9.2 with Infinitest 5.1.103.

Here's my error and my test class:

IllegalStateException (Failed to load ApplicationContext) in OfficeDaoImplTest.testAnything OfficeDaoImplTest.java /office/src/test/java/com/paraware/office/dao line 0 Infinitest Test Failure

import static org.hamcrest.Matchers.*;
import static org.junit.Assert.*;

import java.util.List;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ActiveProfiles;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.TestExecutionListeners;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.support.DependencyInjectionTestExecutionListener;
import org.springframework.test.context.support.DirtiesContextTestExecutionListener;
import org.springframework.test.context.transaction.TransactionalTestExecutionListener;

import com.github.springtestdbunit.DbUnitTestExecutionListener;
import com.github.springtestdbunit.annotation.DatabaseSetup;
import com.paraware.office.domain.Office;
import com.paraware.office.spring.DaoLayerConfiguration;
import com.paraware.office.spring.TestDataSourceConfiguration;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = { DaoLayerConfiguration.class,
        TestDataSourceConfiguration.class })
@TestExecutionListeners({ DependencyInjectionTestExecutionListener.class,
        DirtiesContextTestExecutionListener.class,
        TransactionalTestExecutionListener.class,
        DbUnitTestExecutionListener.class })
@ActiveProfiles("test")
public class OfficeDaoImplTest {

    @Autowired
    private OfficeDao officeDao;

    @Test
    @DatabaseSetup("OfficeDaoImplTest.xml")
    public void testAnything()
    {
        // do anything
    }
}

I also see another failure:

NoSuchMethodError (org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V) in OfficeDaoTest.testAnything2

which is reminiscent of this problem, which leads me to believe the classpath is being set incorrectly:

http://stackoverflow.com/questions/7...h-when-running The recommended fix of moving hamcrest before junit in the classpath fixes the problem.

[Martin Lippert]

Hey!

As mentioned on the other forum post that you are referring to, did you check this maybe also with a pure Eclipse JEE installation to see if this is a general Infinitest problem? Otherwise hard to find out where the problem could be on my end here. Can you try that? That would be awesome!

-Martin

[mjjensen]

I had a similar problem with a Spring Roo generated application, which I fixed by editing the following line in the (generated by Roo) AspectJ file called IntegrationTest_Roo_IntegrationTest.aj ...

declare @type: IntegrationTest: @ContextConfiguration(locations = "classpath:/META-INF/spring/applicationContext*.xml");

I added an asterix after "classpath" and before the ":" ... I would suggest doing something similar to the "locations" parameter of your "@ContextConfiguration()" annotation.

Note that I did this without understanding what the asterix actually does in this case (I assume it does some sort of wildcard matching, perhaps on the name of the CLASSPATH environment variable??), I just saw a similar context configuration in another post while trying to track down a solution for this and I got lucky. Maybe I'll look it up one day :-) Cheers!

Murray...