Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Table Of Contents

Addresses:

  • CPS-95 - Getting issue details... STATUS
  • CPS-124 - Getting issue details... STATUS
  • CPS-128 - Getting issue details... STATUS

Overview

The CPS-RI module which is responsible for data persistence and retrieval from the database is based on
Spring Data framework. Following components are used:

  • Persistence service implementations (logic layer) → these are defined as Java classes
  • JPA repositories (data access layer) → these are defined as Java interfaces, corresponding objects
    are created by Spring framework at runtime

In order to reach the desirable level of reliability it's expected the functionality to be covered with tests.

While using unit tests is a common approach for Java application testing, it seems insufficient  in a context of testing the
actual data persistence/retrieval functionality:

  • Test covers a small slice of functionality while the major piece served by external services (Spring data framework,
    JDBC driver and database itself) remain not used (not tested)
  • JPA repositories can be only used as mocks to test the service implementation but JPA repositories are not subject
    for tests themselves because of definition as interfaces
  • The effort to setup the expected behaviors for JPA repository mocks is comparable with (or exceeds) the effort
    required to setup the actual data for same cases;

From other hand the benefits of using integration tests with real database instance are following:

  • All levels of abstraction are involved in tests, it means all of them are impacting on test results same way as within
    a deployed application
  • JPA repositories are subjects of test
  • Complete validation of expected behavior, including database schema initialization
  • Can be used on build, keeping desired level of reliability and consistency
  • Tests can be used on development stage making the database deployment (on dev environment) optional

Components

Components used to serve the integration tests are shown on diagram below.

  • Docker provides a container with running database instance which is used during the test
  • Test container component communicates with Docker via CLI, manages required container to be created/started
    before test and stopped/removed after the test is completed
  • Test container component is used by JUnit test as a Class Rule
  • The connection to test database is served using standard Spring framework components


Test Containers

Test container life circle management

Database initialization notes


@SpringBootTest


Test template


Resources


  • No labels