Info |
---|
Help is available by sending an email to csf-support@mit.edu |
Panel | ||
---|---|---|
|
Panel |
---|
DefinitionIn 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 |
---|
HistoryUp 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. |
Panel |
---|
The CSF AbstractIntegrationTestBase.java unit test base classCSF now has 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. This CSF abstract class is to be used with all integration tests. It replaces the following deprecated classes
that were used in csf-common-legacy. |
Panel | ||
---|---|---|
|
Panel | ||
---|---|---|
|
Panel | ||
---|---|---|
|
Panel | ||
---|---|---|
|