JUnit Integration Tests

Definition

In our applications and framework, we have used the term "integration test" to describe a written JUnit test case that requires a full Spring context (including all the framework classes), and actually talks to the MITSIS Oracle database. An integration test is disctinct from a pure unit test, which typically uses mock objects for dependencies, and does not talk to the database. We mainly use integration tests for testing DAO classes, but they could possibly be used also for testing service classes and MVC controllers.

History

Up until now (July 2012) our integration test cases (mainly used for testing DAO classes) have extended a base class BaseTransactionalIntegrationTest, which in turn extends deprecated Spring classes.This base class provided unit tests with a default Spring context and an automatic rollback capability. Unit tests extending this base class were automatically database-aware, and any updates done in the unit test were automatically rolled back at the end of the test.

Spring has deprecated the class that BaseTransactionalIntegrationTest extends, and now recommends a different way of coding integration unit tests (see Spring Javadoc). The following section describes changes we are making to move away from the deprecated classes.

New Method of Coding Integration Tests

Here's what we are doing to modernize our integration tests.

1. New Base Class for Integration Tests.
   
   We have created a new abstract class, AbstractIntegrationTestBase class, found in the csf-test module. This class uses JUnit and Spring annotations to gain access to functionality previously provided by extending the deprecated Spring class AbstractTransactionalDataSourceSpringContextTests. The relevant annotations are (at the class level):
   

   @RunWith(SpringJUnit4ClassRunner.class)
   @ContextConfiguration(locations={"classpath:applicationContext-csf-common-config-test.xml",
                   "classpath:applicationContext-csf-webservices.xml",
                   "classpath:applicationContext-csf-common.xml",
                   "classpath:applicationContext-csf-security-spring.xml",
                   "classpath:applicationContext-csf-common-virus.xml",
                   "classpath:applicationContext-csf-common-test.xml" })
   @TestExecutionListeners({TransactionalTestExecutionListener.class, DependencyInjectionTestExecutionListener.class})
   

   @RunWith is a JUnit annotation that tells JUnit to use the Spring-supplied class to run the unit test rather than the default JUnit runner.
   @ContextConfiguration is a Spring annotation that tells the Spring test runner where to load the Spring context from.
   @TestExecutionListeners is a Spring annotation that adds functionality to the test case - in this case, transactional and dependency-injection functionality.
   
   
2. Changes in JUnit test case classes.
   
   • Our JUnit integration tests should now extend the new AbstractIntegrationTestBase class. By doing so, the test class automatically gets the Spring context, and transactional and dependency-injection functionality from the base class. If required, the context configuration can be overriden simply by adding a similar @ContextConfiguration annotation to the test class.
     
   • To get the automatic rollback functionality, each JUnit test method should be annotated with @Transactional.
     
   • Beans can be injected automatically by using the @Autowired annotation.
     For a sample JUnit Integration test using the new method, take a look at edu.mit.common.dao.academic.hibernate.TestHibernateAcademicTermDao in the csf-common-legacy module.