Home » Java » Enterprise Java » Spring Testing Support and Context caching

About Biju Kunjummen

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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

3 comments

  1. nice work

  2. The article helps clarify the questions I could not understand when reading the spring documents, thank you.

  3. Hello, Biju,
    Thank you for describing your experience, it helped me to understand my issue. As I am using @Configuration without locations (that are used as keys in context cache), two tests even with different Config classes (I am using Java configuration instead of XML) finish up with the same context that was loaded first, having {} as a key.

    Do you know, how could I change the key in the cache of org.springframework.test.context.TestContextManager#contextCache?

    Thanks
    Jety

Leave a Reply

Your email address will not be published. Required fields are marked *

*


6 − = zero

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Do you want to know how to develop your skillset and become a ...

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!
Get ready to Rock!
To download the books, please verify your email address by following the instructions found on the email we just sent you.

THANK YOU!

Close