Simple Spring Junit -

[Sharon whipple]

Hi,
Sorry for the dumb question I am newbie to Spring...
I am trying to run simple spring junit code from:
http://hamletdarcy.blogspot.com/2008/12/autowired-junit-tests-with-spring-25.html

I am stuck with exception :
BeanDefinitionStoreException: IOException parsing XML document from class path resource ....
Nested:
Caused by: java.io.FileNotFoundException: class path resource [Web root/WEB-INF/applicationContext.xml] cannot be opened because it does not exist

The applicationContext is configured with the ContextConfiguration annotation,
the xml files lie in Web root/WEB-INF/**context.xml

The Junit test exist in the same folder as the rest of the Java sources under
com.companty.test

The JUnit Code:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"/Web root/WEB-INF/applicationContext.xml",
				"/Web root/WEB-INF/internalAppContext.xml"})

public class TestService {
	
	@Autowired
	@Qualifier("myService")
	privateMyService service;
	
	
	@BeforeClass
	public static void setUpBeforeClass() throws Exception {
	
	try{		
		ServletContext servletContext = new MockServletContext("/Web root",
	                new FileSystemResourceLoader());
		ContextUtil.init(servletContext);
	}catch(Exception e){
		Assert.fail(e.getMessage());
	}
	}
	
	@Test
	@DirtiesContext
	public void getViewsTest() {
		if(alertsService!=null){
			List<ViewHib> viewList = service.getViews();
			if(viewList ==null || viewList.isEmpty()){
					Assert.fail("unable to find views");
			}
			for (ViewHib view : viewList) {
				System.out.println("service output" + view.getName());
			}
				
		}
		else
			Assert.fail("MyService was not injected!");
	}
}

TIA

[Mark Spritzler]

Well, you will have a different xml file for your Unit tests. I would assume you want to unit test a class in isolation, so you would need to use mocks or stubs, and that would be a different bean configuration for unit tests that you would need.

So I would create a different xml file for your unit tests. And you might have multiple xml files for different unit tests. For instance you have your Service unit tests and you probably have your dao/repository unit tests, each class would have different mocks and stubs that are being used, so they would each have their own xml files.

By breaking up your xml files too based on the type of beans in them, then you make it a little easier to have different xml files for different environments. One for dev, some for unit tests, and for production.

Mark

[Sharon whipple]

create stubs mocks and context xml for each test? that's really a overhead,
Why not to load the application context xml, and test the services/dao with the same configuration of the prod?

Shaorn

[Mark Spritzler]

Sharon whipple wrote:create stubs mocks and context xml for each test? that's really a overhead,
Why not to load the application context xml, and test the services/dao with the same configuration of the prod?

Shaorn

Not exactly the way you put it. The Unit Tests xml would be just the configuration that is different in that environment.

As far as the Application Context, because you have all your services and dao/repositories defined in an xml in the WEB-INF directory, you just tied that configuration of beans to the web environment only. So if you wanted the same somewhere else, you would have to repeat yourself. I would recommend creating an application-config.xml in your java code classpath, and in your WEB-INF create a file called applicationContext.xml and import that application-config.xml

And in your unit test, you can create a test-infrastructure.xml config file that imports the application-config.xml. So that the stuff that is shared across environments is in a location all environments can get to.

Mark

[Sharon whipple]

Currently we have two configuration files:
company_applicationContext.xml defining the connectionManager, drivers,AuthenticationProvider etc
InternalAppContext.xml defining all the application services and dao
mvc-servlet.xml defining Controllers& mappings


so if i understand correctly
The curent situation is

Root folder-|
   Java source-|
       com.company.package
       com.company.test

   Web root -|
       WEB-INF-|
            mvc-servlet.xml
              config-|
                            company_applicationContext.xml  
                            internalAppContext.xml

Your suggestion:

Root folder-|
    company_applicationContext.xml  (say a)

   Java source-|
       com.company.package

   Test sources-| 
       com.company.test-|
	test-infrastructure.xml (include a)

   Web root -|
       WEB-INF-|
            mvc-servlet.xml
              config-|
                            applicationContext.xml (include a)
                            internalAppContext.xml (include a)

Sorry if I am nagging ,
What is the diffarence between test-infrastructure and applicationContext.xml, is it just the definition of the services Dao being tested?
Why not leave the applicationContext.xml in WEB-INF and including it in the test-infrastructure.xml?

Thank you.

[Mark Spritzler]

It is about putting the specific configuration file in the location that is closest to where it is defined, so that you can re-use and not have to write lots of xml.

So in you Java folder you have your pojo services and dao/repositories. Since they can be used in the Web environment and the Unit test environment, on a dev box, or an integration box, or in production, they all need configuration files, and it would be best to just import the shared xml files in those individual environment xml files. Just like you would do with class hierarchies. You want to maximize re-use and minimize duplication.

So I can declare my services and dao beans in an xml file where the code is. Then in the environments, just import that xml. So in the JUnit test directory have a test-infrastructure.xml file. Import the application-config.xml, and define any specific beans to the test environment in the test-infrastructure.xml.

The problem with defining your services and dao/repositories in the app context xml file in the WEB-INF directory, is that your JUnit test environment will not have access to the WEB-INF directory, and it shouldn't.

Mark