-
Notifications
You must be signed in to change notification settings - Fork 4
Managing Test Artifacts
Several types of test artifacts are managed by FHIR Toolkit. This document describes how to manage these artifacts.
All the necessary artifacts are delivered with the toolkit. As delivered they reside in
asbestos-war/src/main/webapp/data/
Under here are three directories
Channels
TestAssertions
TestCollections
which contain the default channels, test assertion documentation, and tests (organized into collections).
When the FHIR Toolkit web app (named asbestos) starts, These directories are copied to the External Cache. It is the External Cache copy that is used by the running toolkit. More specifically
Channels is copied to FhirChannels (in the external cache)
TestAssertions is copied to FhirTestAssertions (in the external cache)
TestCollections is copied to FhirTestCollections (in the external cache)
This copy operation always happens at startup unless the file ExternalCache/FhirTestCollections.lock exists. If this file is present then the External Cache copy of these artifacts is considered locked and will not be updated.
You can add or update locally written test artifacts to the External Cache at any time. They are protected from overwrite by the lock file. They are available for use in the tool as soon as they are saved from you editor.
When installing a FHIR Toolkit update, updated test artifacts from the new installation will not be written to the External Cache (and be available for use in the tool) until you remove FhirTestCollections.lock and restart Tomcat.
This update cycle does not delete the existing contents, just overwrites them. So if the new release removed a test artifact from the distribution you will still have it in your External Cache after the update. But, your local data will not be harmed.
Each test collection is labeled as either client or server. See below for the distinction between these types.
A test collection is a directory (collection) of test definitions. Each directory defines one test. A test directory has a prescribed structure (see below). In the test collection directory is a mandatory file TestCollection.properties which holds properties of the collection.
As an example
TestType: client
TestType can have one other value - server. This defines whether the test collection holds client or server tests.
Other properties can exist.
Cache: true
is used in the Patient loader to indicate that a cache should be maintained and only a single instance should be maintained in the server. Note that I'm not sure this is general and reusable yet. YMMV SDFD.
And
Channel: default
says always run these TestScripts in the coded channel.
A client test contains a single file TestScript.xml (could be .json) containing a single TestScript resource. The TestScript may have many test elements but the test element may contain only assert elements (no operation elements). This type of test is passive - it does not generate any READs or WRITEs. I has only ASSERTs which are evaluated against a pre-defined resource which is extracted from the proxy logs by the test engine. When a client test is run, two fixtures are pre-defined: request (the request resource) and response (the response resource).
A client test contains a single file TestScript.xml (could be .json) containing a single TestScript resource. The TestScript may have many test elements and each test element may contain both operation and assert elements.
TBD