Overview
Documents the approach to functional/integration testing for the application JPA services layer.
NOTE: focus is on implementing REST tests which implicitly perform most of the coverage needed here.
Coverage
There are four services, each with a JPA implementation
- Root Service (top level)
- Security Service
- Metadata Service
- Content Service
- History Service
Complete coverage would address each mode of use of each method call of each service. It would also consider where different types of mapping projects would expect to have different outcomes (e.g. an "extended map" vs. a "complex map").
Coverage Definition
The attached spreadsheet formally defines JPA service layer coverage from an integration testing perspective.
Assumptions
- A dev database exists that is loaded with exactly the development content config/ project.
- Any changes made are reverted to initial conditions so all tests can assume identical initial conditions
Coverage is defined in a multi-dimensional matrix that takes into account the services, the methods of the services, and the modes of use of the services (including normal use, degenerate use, and edge cases). NOTE: in many cases there are many "normal" modes of use which may extend the number of columns in the spreadsheet. For example, GUIs that respond differently to different authorization levels, or methods that take optional parameters (e.g. Pfs). Coverage also considers combinations of calls that have related effects to each other and a placeholder for "ad hoc" tests that can be filled in as gaps in coverage are identified.
The following sample coverage spreadsheet begins to outline the methodology for defining coverage though it is not fully fleshed out.
Organization
Integration tests are organized under the integration-testing project. Looking through the Java packages, you should find a "jpa" package that defines a number of test classes that represent the coverage spreadsheet.
Each column of each tab of the coverage spreadsheet is represented by a single testing class, where each row within that column corresponds to a particular method of that testing class. The coverage spreadsheet defines both the class names used to implement tests as well as the method names (so they can be easily cross referenced).
The test names themselves are "test cases" that are organized into "test suites" according to the structure of the spreadsheet.
For example, the attached coverage spreadsheet has a tab called "Root". Within that spreadsheet is the "Normal Use" column for which there are three rows filled out, implementing testNormalR001, testNormalR002, and testNormalR003. In the integration-tests there is a src/test/java package called "org.ihtsdo.otf.mapping.test.jpa" that contains a testing class "RootServiceNormalUse.java" that has three testing methods corresponding to those listed above. In this way, the organization of the tests within the code correlates to the spreadsheet.
For each test suite and test case, there should also exist documentation. A test suite is a collection of test cases and a test case is a "script" detailing the actions involved and the expected outcomes with any other needed information.
Integration Test Suites
Test suites are organized by spreadsheet tab.
- Root Service Jpa Test Suite
- Security Service Jpa Test Suite
- ... other services test suites ...
- Combo Jpa Test Suites
- TBD
- Ad Hoc Jpa Test Suites
- TBD