Versions Compared

Old Version 10

changes.mady.by.user David E Tanner

Saved on

compared with

New Version Current

changes.mady.by.user Stephen Turner

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Info

Help is available by sending an email to csf-support@mit.edu
Have any suggestion on how improve this wiki?  Please give us your feedback at csf-support@mit.edu

Panel

Quick Links to:

Table of Contents
minLevel3
Panel

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.

...

Panel

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):
    Code Block
    @RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:applicationContext-csf-commonunit-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" tests-default.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. 
    • You should provide the file applicationContext-csf-unit-tests-default.xml. This is a Spring configuration file, and should contain import statements that  reference the Spring context files required by your test. An example can be seen in the csf-iap project (in the es-projects SVN repository).
    • 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.