Versions Compared

Old Version 21

changes.mady.by.user Stephen Turner

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

Quick

Links

to:

{

Panel
Wiki Markup
Table of Contents
:
minLevel
=
3
}
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

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.

h3.

New

Method

of

Coding

Integration

Tests

Here's

what

we

are

doing

to

modernize

our

integration

tests.

# *

  1. New
  1. Base
  1. Class
  1. for
  1. Integration
  1. 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}


  1. 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):

Panel
Wiki Markup
Code Block

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:applicationContext-csf-unit-tests-default.xml"})
@TestExecutionListeners({TransactionalTestExecutionListener.class, DependencyInjectionTestExecutionListener.class})
{code} *@RunWith* is a JUnit annotation that tells JUnit to use the 
  1.  @RunWith is a JUnit annotation that tells JUnit to use the Spring-supplied 
 
  1.  class 
 
  1.  to 
 
  1.  run 
 
  1.  the 
 
  1.  unit 
 
  1.  test 
 
  1.  rather 
 
  1.  than 
 
  1.  the 
 
  1.  default 
 
  1.  JUnit 
 
  1.  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.
\\
\\
# *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 *

  1.  @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 *
    • 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.