Spring Testing Support and Context caching

Spring provides a comprehensive support for unit and integration testing – through annotations to load up a Spring application context, integrate with unit testing frameworks like JUnit and TestNG. Since loading up a large application context for every test takes time, Spring intelligently caches the application context for a test suite – typically when we execute tests for a project, say through ant or maven, a suite is created encompassing all the tests in the project.

There are a few points to note with caching which is what I intend to cover here, this is not likely to be comprehensive but is based on some situations which I have encountered:

1. Caching is based on the locations of Spring application context files

Consider a sample Spring configuration file:

<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<beans xmlns='http://www.springframework.org/schema/beans'
 xmlns:context='http://www.springframework.org/schema/context'
 xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
 xmlns:p='http://www.springframework.org/schema/p'
 xsi:schemaLocation='
  http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
  http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd'>
 
 <bean id='user1'  class='org.bk.lmt.domain.TaskUser' p:username='user1' p:fullname='testUser1' />
 <bean name='user2' class='org.bk.lmt.domain.TaskUser' p:username='user2' p:fullname='testUser' />
 
 <bean class='org.bk.contextcaching.DelayBean'/>
 
</beans>

And a sample test to load up this context file and verify something.:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { 'contexttest.xml' })
public class Test1 {
 @Autowired Map<String, TaskUser> usersMap;

 @Test
 public void testGetAUser() {
  TaskUser user = usersMap.get('user1');
  assertThat(user.getFullname(), is('testUser1'));
 }
}

I have deliberately adding in a bean(DelayBean) which takes about 2 seconds to instantiate, to simulate Spring Application Contexts which are slow to load up.

If I now run a small test suite with two tests, both using the same application context, the behavior is that the first test takes about 2 seconds to run through, but the second test runs through quickly because of context caching.

If there were a third test using a different application context, this test would again take time to run through as the new application context has to be loaded up:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { 'contexttest2.xml' })
public class Test3 {
...
}

2. Caching of application contexts respects the active profile under which the test is run – essentially the profile is also part of the internal key that Spring uses to cache the context, so if two tests use the exact same application context, but different profiles are active for each of the tests, then the cached application context will not be used for the second test:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { 'contexttest.xml' })
@ActiveProfiles('dev1')
public class Test1 {
....
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { 'contexttest.xml' })
@ActiveProfiles('dev2')
public class Test2 {
....

3. Caching of application context applies even with the new @Configuration style of defining a application context and using it in tests:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes={TestConfiguration.class})
public class Test1 {
...
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes={TestConfiguration.class})
public class Test2 {
....

One implication of caching is that if a test class modifies the state of a bean, then another class in the test suite which uses the cached application context will end up seeing the modified bean instead of the bean the way it was defined in the application context:

For eg. consider two tests, both of which modify a bean in the context, but are asserting on a state the way it is defined in the application context – Here one of the tests would end up failing(based on the order in which Junit executes the tests):

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes={TestConfiguration.class})
public class Test1 {
 @Autowired Map<String, TaskUser> usersMap;


 @Test
 public void testGetAUser1() {
  TaskUser user = usersMap.get('user1');
  assertThat(user.getFullname(), is('testUser1'));
  user.setFullname('New Name');
 }
 
 @Test
 public void testGetAUser2() {
  TaskUser user = usersMap.get('user1');
  assertThat(user.getFullname(), is('testUser1'));
  user.setFullname('New Name');
 }
}

The fix is to instruct Spring test support that the application context is now dirty and needs to be reloaded for other tests, and this is done with @DirtiesContext annotation which can specified at the test class level or test method level.

@Test
@DirtiesContext
public void testGetAUser2() {
...

Happy coding and don’t forget to share!

Reference: Spring Testing Support and Context caching from our JCG partner Biju Kunjummen at the all and sundry blog.