-
Notifications
You must be signed in to change notification settings - Fork 14
Home
A framework for testing the validity of SNOMED CT releases.
git clone https://github.com/IHTSDO/release-validation-framework.git
// -- see note below about config folder
mvn clean install -DrvfConfigLocation=/tmp
The services in the RVF can be configured using property files. Default values for the services are included in the jar files. However, it is possible to override the default values by providing property files for each of the services. The following is a list of property files that can be used to configure services:
| File name | Description | RVF deployment location |
|---|---|---|
| data-service.properties | Settings to configure the data store for RVF domain entities (assertions, test, etc) | /etc/opt/rvf-api/ |
| execution-service.properties | Settings to configure the location of SNOMED CT data used by RVF | /etc/opt/rvf-api/ |
| validation-service.properties | Settings to configure structural tests report location and threshold | /etc/opt/rvf-api/ |
Sample files for configuring the services can be see found in the config folder.
The RVF provides a convenient feature that allows published releases to be uploaded and stored to a designated 'sct data' folder. During startup, the RVF unzips any published release in this folder and loads it into a database as a known release. The following conventions are used by this feature:
| File name | Schema name generated | Comment |
|---|---|---|
| SnomedCT_Release_INT_20140731.zip | rvf_int_20140731 | Created if database named rvf_int_20140731 does not exist |
| SnomedCT_Release_INT_20140731.txt | Not processed | Only zip files are processed |
For more details about loading SNOMED CT releases into RVF, please refer to the Releases wiki page.
While more comprehensive documentation is being prepared, you can find examples of how use the API in the test cases included in the API module. If you are not a Java developer and want to access the API from a non Java environment, then refer to the curl tests/examples in the API-Demo module.
To run unit tests use:
mvn clean test
Integration tests expect an actual MySQL SNOMED CT database that contains SNOMED CT data. To run integration tests use:
mvn clean integration-test -Dskip.integration.tests=false - DrvfConfigLocation=/tmp
Note that all tests in the API that deal with controllers are currently marked as Integration tests. The spring context used by the api-module tries to connect to a MySQL server, which will be missing in Jenkins. So to prevent needless test failure on Jenkins, all these tests have been marked as IntegrationTests. This should be skipped by setting a separate Spring context file for tests that do not require MySQL access.