Trying to implement integration tests in spring...

amy

Hi -

I'm having trouble with doing an integration test for various aspects of my spring configuration (versions 1.2RC2 -gt; 1.2.1 inclusive). I tried first using just a vanilla TestCase in which I created my ApplicationContext in the setUp(). But that was erroring every test (test method and testClass) after the first one (although each one was ok when run on its own). Then I read up and found the very useful AbstractDependencyInjectionSpringContextTests class. Now only the second and subsequent test classes gave errors - in the first class, no problem with subsequent methods.

The traceback for the error concerned is given below. I'm wondering what it really means - It seems like some sort of spring-internal introspection cache is being left in a bad state after the first applicationContext goes out of scope. Is there some sort of tearDown I ought to be doing (I tried doing an applicationContext.close() in my own plain TestCase, but this didn't help, and doesn't seem to be appropriate for the AbstractDependencyInjectionSpringContextTests-derived tests).

Have no clue what I'm doing wrong, so any help would be great...

many thanks

Tim

Traceback (line numbers refer to 1.2.1, I can post 1.2 traceback if that helps).
org..beans.factory.BeanCreationExce  ption: Error creating bean with name 'Class_I7' defined in ucl [file:d:/tdiggins/56Box/TheLaboratory/java/workspace/spring-ui/web/WEB-INF/objects.xml]: Initialization of bean failed; nested exception is java.lang.NullPointerException: null
java.lang.NullPointerException
at org..beans.BeanWrapperImpl.setPrope  rtyValue(BeanWrapperImpl.java:814)
at org..beans.BeanWrapperImpl.setPrope  rtyValue(BeanWrapperImpl.java:716)
at org..beans.BeanWrapperImpl.setPrope  rtyValue(BeanWrapperImpl.java:844)
at org..beans.BeanWrapperImpl.setPrope  rtyValues(BeanWrapperImpl.java:871)
at org..beans.BeanWrapperImpl.setPrope  rtyValues(BeanWrapperImpl.java:860)
at org..beans.factory.support.Abstract  AutowireCapableBeanFactory.applyPropertyValues(Abs  tractAutowireCapableBeanFactory.java:926)
at org..beans.factory.support.Abstract  AutowireCapableBeanFactory.populateBean(AbstractAu  towireCapableBeanFactory.java:727)
at org..beans.factory.support.Abstract  AutowireCapableBeanFactory.createBean(AbstractAuto  wireCapableBeanFactory.java:336)
at org..beans.factory.support.Abstract  BeanFactory.getBean(AbstractBeanFactory.java:223)
at org..beans.factory.support.Abstract  BeanFactory.getBean(AbstractBeanFactory.java:147)
at org..beans.factory.support.DefaultL  istableBeanFactory.preInstantiateSingletons(Defaul  tListableBeanFactory.java:277)
at org..context.support.AbstractApplic  ationContext.refresh(AbstractApplicationContext.ja  va:312)
at org..context.support.ClassPathXmlAp  plicationContext.lt;initgt;(ClassPathXmlApplicationCon  text.java:80)
at org..context.support.ClassPathXmlAp  plicationContext.lt;initgt;(ClassPathXmlApplicationCon  text.java:65)
at org..test.AbstractSpringContextTest  s.loadContextLocations(AbstractSpringContextTests.  java:113)
at org..test.AbstractDependencyInjecti  onSpringContextTests.loadContextLocations(Abstract  DependencyInjectionSpringContextTests.java:165)
at org..test.AbstractSpringContextTest  s.getContext(AbstractSpringContextTests.java:95)
at org..test.AbstractDependencyInjecti  onSpringContextTests.setUp(AbstractDependencyInjec  tionSpringContextTests.java:132)
at junit.framework.TestCase.runBare(TestCase.java:125  )
at junit.framework.TestResult$1.protect(TestResult.ja  va:106)
at junit.framework.TestResult.runProtected(TestResult  .java:124)
at junit.framework.TestResult.run(TestResult.java:109  )
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:2  08)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRu  nner.runTests(RemoteTestRunner.java:474)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRu  nner.run(RemoteTestRunner.java:342)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRu  nner.main(RemoteTestRunner.java:194)

a) I should have mentioned I'm running the integrationtests from within eclipse's junit runner

b) I have found that the problem goes away if I run the junit tests from an ant task - therefore I'm assuming the problem is somehow linked to eclipse?

We run JUnit tests from Eclipse no probs.

We store the ApplicationContext in a ThreadLocal to avoid recreating it for each test.

I think a lot of people on this forum also do exactly the same thing. Can you try that? or do you need to recreate the ApplicationContext each time?

The problem is, I need to test different integration options (ie with different config xml files) -- so therefore (I think) I need to recreate the ApplicationContext from scratch for the differnent configurations.

Am rather new to Spring.

Also, I'm not sure I understand the ThreadLocal idea (have never used a ThreadLocal in a TestCase, or at all come to think of it) -- is this to create the application context so that it can span over multiple testCases/test classes? (And isn't that what AbstractDependencyInjectionSpringContextTest is meant to do...)

A ThreadLocal allows you to attach an Object to the current Thread. It's in java.lang, take a look.

It's a way of passing data between methods/layers without them being explicit method parameters.

If you are going to have a lot of unit tests, you might want to think about having a hierarchy for each configuration that you want to test, and then set/clear a ThreadLocal (or some other cache) with your ApplicationContext for each config change.

It doesn't take long for the ApplicationContext to take 1-2 minutes or more to to load it can save a lot of time for a JUnit to pull the ApplicationContext out of a ThreadLocal or otherwise cached location.

Thanks for helpful info on ThreadLocal, but believe that's the exact benefit of AbstractDependencyInjectionSpringContextTests, so don't think ThreadLocal will help with my problem in this case. However the clarification has enabled me to repost with a clearer explanation of the problem (showthread.php?t=15338)

I think AbstractDependencyInjectionSpringContextTests might have been created after we got our stuff sorted, and we never bothered to look at any other solutions.

I might check out AbstractDependencyInjectionSpringContextTests now myself. Thanks.