-
Notifications
You must be signed in to change notification settings - Fork 4
Adding a validator
This is a work in progress - both the wiki page and the implementation behind it
This discusses adding a validator to the tool which is not linked to an event in the Proxy so the validator must start by fetching a resource to validate. This is different from writing a validator based on a Proxy event. That task is described here.
Non-Inspector based validators (must retrieve resource first) are written in the style of a server test, the TestScript starts by issuing a READ followed by assertions.
At this time we have no examples to point to. In general this is written in the form of a server test.
Necessary parameters: channelId (to get FHIRBASE)
Packaged in separate Test Collection
- TestCollection.vue(sessionId, channelId, testCollection)
- sessionId - where to store the proxy logs
- channelId - what server to it
- testCollection - validations to run
Do we need version of this that does not go through the proxy?
On the server the test collection and one or more tests must be defined. For details see here.
This type of validator should be placed in its own test collection. When issue #61 is completed, such a test collection should be hidden.
The TestScript will be a single READ operation followed by any number of asserts.
TBD - how is the target resource URL passed in?
<TestScript>
<!--
target resource is available in pre-defined variable named target
-->
<test>
<description value="Top level test for UI screen goes here"/>
<action>
<operation>
<description value="target resource"/>
<type>
<code value="read"/>
</type>
<url value="${target}"/>
<responseId value="response"/>
</operation>
</action>
<action>
<assert>
<description value="... read was successful"/>
<response value="okay"/>
<warningOnly value="false"/>
</assert>
</action>
<!--
Other assertions go here
-->
</test>
</TestScript>
Note the coding style.
- Test.description will be the text displayed on the UI for the test.
- Test.action.operation.description will be displayed inside the test on a separate bar for the action (operation). Since it is an operation, the on-screen text will be the operation name (read in this example) followed by the description.
- test.action.assert.description will be displayed inside the test on a separate bar for the action (assertion). Since it is an assertion, it will be prefixed with assert:. The description text should start with three periods (... ). This follows the style for the rest of the toolkit.
For examples of writing assertions, including the use of FHIRPATH, see the existing tests here.