STU 3 Candidate
This page is part of the FHIR Specification (v1.4.0: STU 3 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
. Page versions: R5 R4B R4 R3 R2
| FHIR Infrastructure Work Group | Maturity Level: 0 | Compartments: Not linked to any defined compartments |
TestScript is a resource that specifies a suite of tests against a FHIR server implementation to determine compliance against the FHIR specification.
The TestScript resource is used to define tests that can be executed on one or more FHIR servers. The TestScript resource would typically contain
For example, one TestScript might feature a set of tests focusing on searching Patients and validating the Bundle responses. The fixtures for such a test would contain a list of Patient resources that are required for the test to complete successfully. The setup procedures create the fixtures on the FHIR server being tested. A series of tests execute various search parameters and search for the fixtures in the results. The teardown procedures would then clean up (delete) the fixtures on FHIR server that were created during the setup procedures.
The purpose of the TestScript is to encode in an executable representation tests that can be used to
The TestScript resource should NOT be used to represent Clinical tests, Prescriptions, or any other Healthcare related concept. The TestScript resource is an infrastructure support resource used to represent standardized tests to determine an implementation's level of adherence to the FHIR specification.
The TestScript resource is a part of the conformance framework; its purpose is to test whether systems conform to a set of expectations. The expectations are expressed using a combination of the following resources:
The TestScript resource is designed to establish testing as a first class artifact within the FHIR specification. This resource allows defining a suite of tests that can be executed on one or more FHIR servers and clients. The TestScript resource provides an implementation agnostic description of tests that allows test execution engines to evaluate if a FHIR implementation conforms with the FHIR specification. Providing a clear and concise test methodology for the FHIR specification through the TestScript resource helps to enable interoperability among various FHIR server and client implementations.
Furthermore, the TestScript resource provides clear examples of the appropriate use of the FHIR specification through test-based documentation. The TestScript resource stands as a form of executable documentation allowing developers to examine the operations defined by the tests in order to understand how various RESTful API interactions and resources should be used in coordination. The tests can also be automatically executed against systems under development to determine how well the systems adhere to the specification.
The TestScript resource contains:
Pre-Processing
The TestScript execution workflow begins by determining if the test suite is appropriate for the server under test. This can be determined by evaluating if the interactions listed in the TestScript metadata "capabilities" section are supported by the server's conformance resource. If the capabilities are supported by the server, then the TestScript can be executed. Otherwise, the TestScript as a whole or a specific test within the test script may be skipped depending on where the capabilities section is defined. See How to specify metadata capabilities.
If the server supports the requirements of the TestScript instance, any specified fixtures are loaded or retrieved. If the fixtures are marked as 'autocreate' then they are automatically created on the server(s) under test using 'create' operations. If any of the autocreate operations fail, then the tests in the TestScript are skipped.
Setup Execution
After the fixtures are loaded and autocreates are executed, then the setup section is executed to establish the test suite environment. The purpose of the setup section is typically to pre-load data (if it was not autocreated) required for the execution of the tests into the FHIR server under test. The setup operations are executed once before all the tests are run (see Operation Execution). All operations in a setup section (including assertions) must complete successfully for the tests to be executed. If an assertion operation in the setup section fails, then execution and evaluation of the tests in the TestScript should be skipped. Technically, any operation (see the operations table for a complete listing) can be included in the setup section, but typical operations will be create, update, read, and vread.
Due to the possibility that the setup actions are not required on the server under test, the TestScript execution workflow MAY provide the capability of skipping or ignoring the setup section of the TestScript.
Test Execution
Once setup is complete, each test is executed. Tests contain a set of operations, and executing a test involves the evaluation of each operation listed in the test in the order defined by the test (see Operation Execution and the list of operations).
Teardown Execution
After all the tests have completed execution, the teardown section is executed. The purpose of the teardown section is to revert the FHIR server under test to a pre-test clean state. This requires removing any resources or artifacts generated as part of test suite setup or test execution. Technically, any operation (see the operations table for a complete listing) can be included in the teardown section, but the most often used operation will be delete. Assertions are not supported in the teardown section.
Due to the possibility that the teardown actions are not required on the server under test, the TestScript execution workflow MAY provide the capability of skipping or ignoring the teardown section of the TestScript.
Post-Processing
After the teardown section is executed, any fixtures that were marked 'autodelete' are removed from the server(s) under test. After this final stage, the execution of the TestScript is complete.
The fixtures section of the TestScript defines a set of resource instances that will be used as part of the setup, test, and teardown sections during TestScript execution. All defined fixtures are expected to be required in order for the test script to execute. Each fixture defines a resource instance by URI, and must be identified by an ID. The URI can be local or remote (i.e. another server than the one the TestScript resource resides), absolute or relative. The ID on the fixture is considered the "source" identifier of the fixture -- it is not the same thing as the resource ID on the server where it was hosted. The "source" identifier is used to define the fixture instance within the context of the TestScript. Operations reference the ID of a fixture to uniquely identify the fixture instance the operation is using ("sourceId") or acting against ("targetId"). Once a fixture has been instantiated on a server (typically by the use of a create operation), the fixture ID is mapped to the ID of the corresponding resource instance on the server. TestScript execution engines must maintain this relationship between fixture IDs and server resource IDs. The TestScript execution engine is responsible for translating the fixture IDs (whether provided to the operation as "source" or "target") to the ID of the resource on the server during execution.
Using the optional "autocreate" and "autodelete" elements (missing values default to false), fixtures can be configured to automatically be created during TestScript setup and automatically deleted during TestScript teardown. This means that additional "create" and "delete" operations in the TestScript.setup and TestScript.teardown sections are unnecessary.
The variables section of the TestScript defines a set of expressions whose evaluations will be used in substitutions. These substitutions are performed in operation request headers and URL paths as well as assertion values.
Without variables, search parameters and request headers (such as If-Modified-Since) would be specified in outgoing requests as literal values. Variables allow the values to be managed externally in fixtures or dynamically in server response fixtures. They would be defined to hold path expressions against the fixtures. The path expressions would not change from one server to another but the fixture data could.
Using variables allows for the same test scripts to be executed against the same servers by different clients at the same time. Each client would change the fixture data (external to the test script) to make the data unique to that client. This ensures that the same delete/create/read operations executed concurrently by one client does not interfere with those of a another client. That can be important within the context of a testing event such as a Connectathon. It can be very useful in year-round testing against public servers as well.
See Use variables for more information.
The setup, test, and teardown sections of a TestScript can contain operation elements. Operations are intended to be executed in sequence and they represent the logic defined by the TestScript. Operations define a type, sourceId, targetid, destination, responseId, contentType, and other parameters. The type of the operation aligns with a corresponding RESTful API interaction. The sourceId and targetId of an operation define the context of the fixture data the operation is acting against (see Fixtures). The destination defines the server the operation is executed on and is only required for tests that include multiple servers. The responseId specifies a fixture ID to use to map to the server response. The contentType defines the format (XML or JSON) and the corresponding mime-type (application/xml+fhir and application/json+fhir) to use in the RESTful operation (defaulting to XML). The parameters of an operation allow providing additional data required for execution.
TestScript execution engines must load the operation details and execute the operation against the server(s) under test. Operations that are expected to result in an error or exception, shall immediately be followed by one or more "assertion" operations (that test for those error conditions), otherwise the test fails. This allows for "negative" testing (for example, the test script may perform operations that should return a 4XX or 5XX HTTP response code). Test execution is halted as soon as an operation or assertion fails. If an operation or assertion fails, then the test ends in failure and the test script execution proceeds to the next test. Once all tests have completed execution, the teardown section is executed. Once teardown completes, the suite execution is complete. If any setup or test operation or assertion failed, the test script is marked in failure. Failures in teardown are ignored.
The "assertion" evaluates the results of previous operations to determine if the server under test behaves appropriately. In order to evaluate an assertion, the request, response, and results of the most recently executed operation must always be maintained by the TestScript execution engine.
The TestScript execution engine must implement the behavior of each assertion to determine if the response of the last operation meets the conditions of the assertion.
If the conditions of the assertion are met execution of the test continues. If the conditions of the assertion are not met, the test being executed fails and execution of the test is halted.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
  TestScript | DomainResource | Describes a set of tests | ||
  url | Σ | 1..1 | uri | Absolute URL used to reference this TestScript |
| version | Σ | 0..1 | string | Logical id for this version of the TestScript |
| name | Σ | 1..1 | string | Informal name for this TestScript |
| status | ?! Σ | 1..1 | code | draft | active | retired ConformanceResourceStatus (Required) |
 identifier | Σ | 0..1 | Identifier | External identifier |
| experimental | Σ | 0..1 | boolean | If for testing purposes, not real usage |
| publisher | Σ | 0..1 | string | Name of the publisher (Organization or individual) |
 contact | Σ | 0..* | BackboneElement | Contact details of the publisher |
 name | Σ | 0..1 | string | Name of an individual to contact |
 telecom | Σ | 0..* | ContactPoint | Contact details for individual or publisher |
| date | Σ | 0..1 | dateTime | Date for this version of the TestScript |
| description | Σ | 0..1 | string | Natural language description of the TestScript |
| useContext | Σ | 0..* | CodeableConcept | Content intends to support these contexts Context of Use ValueSet (Extensible) |
| requirements | 0..1 | string | Scope and Usage this Test Script is for | |
| copyright | 0..1 | string | Use and/or publishing restrictions | |
| origin | 0..* | BackboneElement | An abstract server representing a client or sender in a message exchange | |
| index | 1..1 | integer | The index of the abstract origin server starting at 1 | |
| profile | 1..1 | Coding | FHIR-Client | FHIR-SDC-FormFiller TestScriptProfileOriginType (Extensible) | |
| destination | 0..* | BackboneElement | An abstract server representing a destination or receiver in a message exchange | |
| index | 1..1 | integer | The index of the abstract destination server starting at 1 | |
| profile | 1..1 | Coding | FHIR-Server | FHIR-SDC-FormManager | FHIR-SDC-FormReceiver | FHIR-SDC-FormProcessor TestScriptProfileDestinationType (Extensible) | |
| metadata | I | 0..1 | BackboneElement | Required capability that is assumed to function correctly on the FHIR server being tested TestScript metadata capability SHALL contain required or validated or both. |
| link | 0..* | BackboneElement | Links to the FHIR specification | |
| url | 1..1 | uri | URL to the specification | |
| description | 0..1 | string | Short description | |
| capability | 1..* | BackboneElement | Capabilities that are assumed to function correctly on the FHIR server being tested | |
 required | 0..1 | boolean | Are the capabilities required? | |
| validated | 0..1 | boolean | Are the capabilities validated? | |
| description | 0..1 | string | The expected capabilities of the server | |
| origin | 0..* | integer | Which origin server these requirements apply to | |
| destination | 0..1 | integer | Which server these requirements apply to | |
| link | 0..* | uri | Links to the FHIR specification | |
 conformance | 1..1 | Reference(Conformance) | Required Conformance | |
| fixture | 0..* | BackboneElement | Fixture in the test script - by reference (uri) | |
| autocreate | 0..1 | boolean | Whether or not to implicitly create the fixture during setup | |
| autodelete | 0..1 | boolean | Whether or not to implicitly delete the fixture during teardown | |
| resource | 0..1 | Reference(Any) | Reference of the resource | |
| profile | 0..* | Reference(Any) | Reference of the validation profile | |
| variable | I | 0..* | BackboneElement | Placeholder for evaluated elements Variable cannot contain both headerField and path. |
| name | 1..1 | string | Descriptive name for this variable | |
| defaultValue | 0..1 | string | Default, hard-coded, or user-defined value for this variable | |
| headerField | 0..1 | string | HTTP header field name for source | |
| path | 0..1 | string | XPath or JSONPath against the fixture body | |
| sourceId | 0..1 | id | Fixture Id of source expression or headerField within this variable | |
| rule | 0..* | BackboneElement | Assert rule used within the test script | |
| resource | 1..1 | Reference(Any) | Assert rule resource reference | |
| param | 0..* | BackboneElement | Rule parameter template | |
| name | 1..1 | string | Parameter name matching external assert rule parameter | |
| value | 0..1 | string | Parameter value defined either explicitly or dynamically | |
| ruleset | 0..* | BackboneElement | Assert ruleset used within the test script | |
| resource | 1..1 | Reference(Any) | Assert ruleset resource reference | |
| rule | 1..* | BackboneElement | Id of referenced rule within the ruleset | |
| param | 0..* | BackboneElement | Ruleset rule parameter template | |
| name | 1..1 | string | Parameter name matching external assert ruleset rule parameter | |
| value | 0..1 | string | Parameter value defined either explicitly or dynamically | |
| setup | 0..1 | BackboneElement | A series of required setup operations before tests are executed | |
 metadata | I | 0..1 | see metadata | Capabilities that are assumed to function correctly on the FHIR server being tested Setup metadata capability SHALL contain required or validated or both. |
| action | I | 1..* | BackboneElement | A setup operation or assert to perform Setup action SHALL contain either an operation or assert but not both. |
| operation | I | 0..1 | BackboneElement | The setup operation to perform Setup operation SHALL contain either sourceId or targetId or params or url. |
| type | 0..1 | Coding | The operation code type that will be executed TestScriptOperationCode (Extensible) | |
| resource | 0..1 | code | Resource type FHIRDefinedType (Required) | |
| label | 0..1 | string | Tracking/logging operation label | |
| description | 0..1 | string | Tracking/reporting operation description | |
| accept | 0..1 | code | xml | json ContentType (Required) | |
| contentType | 0..1 | code | xml | json ContentType (Required) | |
| destination | 0..1 | integer | Server responding to the request | |
| encodeRequestUrl | 0..1 | boolean | Whether or not to send the request url in encoded format | |
| origin | 0..1 | integer | Server initiating the request | |
| params | 0..1 | string | Explicitly defined path parameters | |
| requestHeader | 0..* | BackboneElement | Each operation can have one ore more header elements | |
| field | 1..1 | string | HTTP header field name | |
| value | 1..1 | string | HTTP headerfield value | |
| responseId | 0..1 | id | Fixture Id of mapped response | |
| sourceId | 0..1 | id | Fixture Id of body for PUT and POST requests | |
| targetId | 0..1 | id | Id of fixture used for extracting the [id], [type], and [vid] for GET requests | |
| url | 0..1 | string | Request URL | |
| assert | I | 0..1 | BackboneElement | The assertion to perform Setup action assert shall contain both compareToSourceId and compareToSourcePath or neither. Only a single assertion SHALL be present within setup action assert element. |
| label | 0..1 | string | Tracking/logging assertion label | |
| description | 0..1 | string | Tracking/reporting assertion description | |
| direction | 0..1 | code | response | request AssertionDirectionType (Required) | |
| compareToSourceId | 0..1 | string | Id of fixture used to compare the "sourceId/path" evaluations to | |
| compareToSourcePath | 0..1 | string | XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to | |
| contentType | 0..1 | code | xml | json ContentType (Required) | |
| headerField | 0..1 | string | HTTP header field name | |
| minimumId | 0..1 | string | Fixture Id of minimum content resource | |
| navigationLinks | 0..1 | boolean | Perform validation on navigation links? | |
| operator | 0..1 | code | equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains AssertionOperatorType (Required) | |
| path | 0..1 | string | XPath or JSONPath expression | |
| resource | 0..1 | code | Resource type FHIRDefinedType (Required) | |
| response | 0..1 | code | okay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessable AssertionResponseTypes (Required) | |
| responseCode | 0..1 | string | HTTP response code to test | |
| rule | 0..1 | BackboneElement | Id of the TestScript.rule | |
| param | 0..* | BackboneElement | Rule parameter template | |
| name | 1..1 | string | Parameter name matching external assert rule parameter | |
| value | 1..1 | string | Parameter value defined either explicitly or dynamically | |
| ruleset | 0..1 | BackboneElement | Id of the TestScript.ruleset | |
| rule | 1..* | BackboneElement | Id of referenced rule within the ruleset | |
| param | 0..* | BackboneElement | Rule parameter template | |
| name | 1..1 | string | Parameter name matching external assert ruleset rule parameter | |
| value | 1..1 | string | Parameter value defined either explicitly or dynamically | |
| sourceId | 0..1 | id | Fixture Id of source expression or headerField | |
| validateProfileId | 0..1 | id | Profile Id of validation profile reference | |
| value | 0..1 | string | The value to compare to | |
| warningOnly | 0..1 | boolean | Will this assert produce a warning only on error? | |
| test | 0..* | BackboneElement | A test in this script | |
| name | 0..1 | string | Tracking/logging name of this test | |
| description | 0..1 | string | Tracking/reporting short description of the test | |
| metadata | I | 0..1 | see metadata | Capabilities that are expected to function correctly on the FHIR server being tested Test metadata capability SHALL contain required or validated or both. |
| action | I | 1..* | BackboneElement | A test operation or assert to perform Test action SHALL contain either an operation or assert but not both. |
| operation | I | 0..1 | see operation | The setup operation to perform Test operation SHALL contain either sourceId or targetId or params or url. |
| assert | I | 0..1 | see assert | The setup assertion to perform Test action assert shall contain both compareToSourceId and compareToSourcePath or neither. Only a single assertion SHALL be present within test action assert element. |
| teardown | 0..1 | BackboneElement | A series of required clean up steps | |
| action | I | 1..* | BackboneElement | One or more teardown operations to perform Teardown action SHALL contain an operation. |
| operation | I | 0..1 | see operation | The teardown operation to perform Teardown operation SHALL contain either sourceId or targetId or params or url. |
| Documentation for this format | ||||
UML Diagram
XML Template
<TestScript xmlns="http://hl7.org/fhir"><!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension --> <url value="[uri]"/><!-- 1..1 Absolute URL used to reference this TestScript --> <version value="[string]"/><!-- 0..1 Logical id for this version of the TestScript --> <name value="[string]"/><!-- 1..1 Informal name for this TestScript --> <status value="[code]"/><!-- 1..1 draft | active | retired --> <identifier><!-- 0..1 Identifier External identifier --></identifier> <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage --> <publisher value="[string]"/><!-- 0..1 Name of the publisher (Organization or individual) --> <contact> <!-- 0..* Contact details of the publisher --> <name value="[string]"/><!-- 0..1 Name of an individual to contact --> <telecom><!-- 0..* ContactPoint Contact details for individual or publisher --></telecom> </contact> <date value="[dateTime]"/><!-- 0..1 Date for this version of the TestScript --> <description value="[string]"/><!-- 0..1 Natural language description of the TestScript --> <useContext><!-- 0..* CodeableConcept Content intends to support these contexts --></useContext> <requirements value="[string]"/><!-- 0..1 Scope and Usage this Test Script is for --> <copyright value="[string]"/><!-- 0..1 Use and/or publishing restrictions --> <origin> <!-- 0..* An abstract server representing a client or sender in a message exchange --> <index value="[integer]"/><!-- 1..1 The index of the abstract origin server starting at 1 --> <profile><!-- 1..1 Coding FHIR-Client | FHIR-SDC-FormFiller --></profile> </origin> <destination> <!-- 0..* An abstract server representing a destination or receiver in a message exchange --> <index value="[integer]"/><!-- 1..1 The index of the abstract destination server starting at 1 --> <profile><!-- 1..1 Coding FHIR-Server | FHIR-SDC-FormManager | FHIR-SDC-FormReceiver | FHIR-SDC-FormProcessor --></profile> </destination> <metadata> <!-- 0..1 Required capability that is assumed to function correctly on the FHIR server being tested --> <link> <!-- 0..* Links to the FHIR specification --> <url value="[uri]"/><!-- 1..1 URL to the specification --> <description value="[string]"/><!-- 0..1 Short description --> </link> <capability> <!-- 1..* Capabilities that are assumed to function correctly on the FHIR server being tested --> <required value="[boolean]"/><!-- 0..1 Are the capabilities required? --> <validated value="[boolean]"/><!-- 0..1 Are the capabilities validated? --> <description value="[string]"/><!-- 0..1 The expected capabilities of the server --> <origin value="[integer]"/><!-- 0..* Which origin server these requirements apply to --> <destination value="[integer]"/><!-- 0..1 Which server these requirements apply to --> <link value="[uri]"/><!-- 0..* Links to the FHIR specification --> <conformance><!-- 1..1 Reference(Conformance) Required Conformance --></conformance> </capability> </metadata> <fixture> <!-- 0..* Fixture in the test script - by reference (uri) --> <autocreate value="[boolean]"/><!-- 0..1 Whether or not to implicitly create the fixture during setup --> <autodelete value="[boolean]"/><!-- 0..1 Whether or not to implicitly delete the fixture during teardown --> <resource><!-- 0..1 Reference(Any) Reference of the resource --></resource> </fixture> <profile><!-- 0..* Reference(Any) Reference of the validation profile --></profile> <variable> <!-- 0..* Placeholder for evaluated elements --> <name value="[string]"/><!-- 1..1 Descriptive name for this variable --> <defaultValue value="[string]"/><!-- 0..1 Default, hard-coded, or user-defined value for this variable --> <headerField value="[string]"/><!-- 0..1 HTTP header field name for source --> <path value="[string]"/><!-- 0..1 XPath or JSONPath against the fixture body --> <sourceId value="[id]"/><!-- 0..1 Fixture Id of source expression or headerField within this variable --> </variable> <rule> <!-- 0..* Assert rule used within the test script --> <resource><!-- 1..1 Reference(Any) Assert rule resource reference --></resource> <param> <!-- 0..* Rule parameter template --> <name value="[string]"/><!-- 1..1 Parameter name matching external assert rule parameter --> <value value="[string]"/><!-- 0..1 Parameter value defined either explicitly or dynamically --> </param> </rule> <ruleset> <!-- 0..* Assert ruleset used within the test script --> <resource><!-- 1..1 Reference(Any) Assert ruleset resource reference --></resource> <rule> <!-- 1..* Id of referenced rule within the ruleset --> <param> <!-- 0..* Ruleset rule parameter template --> <name value="[string]"/><!-- 1..1 Parameter name matching external assert ruleset rule parameter --> <value value="[string]"/><!-- 0..1 Parameter value defined either explicitly or dynamically --> </param> </rule> </ruleset> <setup> <!-- 0..1 A series of required setup operations before tests are executed --> <metadata><!-- 0..1 Content as for TestScript.metadata Capabilities that are assumed to function correctly on the FHIR server being tested --></metadata> <action> <!-- 1..* A setup operation or assert to perform --> <operation> <!-- 0..1 The setup operation to perform --> <type><!-- 0..1 Coding The operation code type that will be executed --></type> <resource value="[code]"/><!-- 0..1 Resource type --> <label value="[string]"/><!-- 0..1 Tracking/logging operation label --> <description value="[string]"/><!-- 0..1 Tracking/reporting operation description --> <accept value="[code]"/><!-- 0..1 xml | json --> <contentType value="[code]"/><!-- 0..1 xml | json --> <destination value="[integer]"/><!-- 0..1 Server responding to the request --> <encodeRequestUrl value="[boolean]"/><!-- 0..1 Whether or not to send the request url in encoded format --> <origin value="[integer]"/><!-- 0..1 Server initiating the request --> <params value="[string]"/><!-- 0..1 Explicitly defined path parameters --> <requestHeader> <!-- 0..* Each operation can have one ore more header elements --> <field value="[string]"/><!-- 1..1 HTTP header field name --> <value value="[string]"/><!-- 1..1 HTTP headerfield value --> </requestHeader> <responseId value="[id]"/><!-- 0..1 Fixture Id of mapped response --> <sourceId value="[id]"/><!-- 0..1 Fixture Id of body for PUT and POST requests --> <targetId value="[id]"/><!-- 0..1 Id of fixture used for extracting the [id], [type], and [vid] for GET requests --> <url value="[string]"/><!-- 0..1 Request URL --> </operation> <assert> <!-- 0..1 The assertion to perform --> <label value="[string]"/><!-- 0..1 Tracking/logging assertion label --> <description value="[string]"/><!-- 0..1 Tracking/reporting assertion description --> <direction value="[code]"/><!-- 0..1 response | request --> <compareToSourceId value="[string]"/><!-- 0..1 Id of fixture used to compare the "sourceId/path" evaluations to --> <compareToSourcePath value="[string]"/><!-- 0..1 XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to --> <contentType value="[code]"/><!-- 0..1 xml | json --> <headerField value="[string]"/><!-- 0..1 HTTP header field name --> <minimumId value="[string]"/><!-- 0..1 Fixture Id of minimum content resource --> <navigationLinks value="[boolean]"/><!-- 0..1 Perform validation on navigation links? --> <operator value="[code]"/><!-- 0..1 equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains --> <path value="[string]"/><!-- 0..1 XPath or JSONPath expression --> <resource value="[code]"/><!-- 0..1 Resource type --> <response value="[code]"/><!-- 0..1 okay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessable --> <responseCode value="[string]"/><!-- 0..1 HTTP response code to test --> <rule> <!-- 0..1 Id of the TestScript.rule --> <param> <!-- 0..* Rule parameter template --> <name value="[string]"/><!-- 1..1 Parameter name matching external assert rule parameter --> <value value="[string]"/><!-- 1..1 Parameter value defined either explicitly or dynamically --> </param> </rule> <ruleset> <!-- 0..1 Id of the TestScript.ruleset --> <rule> <!-- 1..* Id of referenced rule within the ruleset --> <param> <!-- 0..* Rule parameter template --> <name value="[string]"/><!-- 1..1 Parameter name matching external assert ruleset rule parameter --> <value value="[string]"/><!-- 1..1 Parameter value defined either explicitly or dynamically --> </param> </rule> </ruleset> <sourceId value="[id]"/><!-- 0..1 Fixture Id of source expression or headerField --> <validateProfileId value="[id]"/><!-- 0..1 Profile Id of validation profile reference --> <value value="[string]"/><!-- 0..1 The value to compare to --> <warningOnly value="[boolean]"/><!-- 0..1 Will this assert produce a warning only on error? --> </assert> </action> </setup> <test> <!-- 0..* A test in this script --> <name value="[string]"/><!-- 0..1 Tracking/logging name of this test --> <description value="[string]"/><!-- 0..1 Tracking/reporting short description of the test --> <metadata><!-- 0..1 Content as for TestScript.metadata Capabilities that are expected to function correctly on the FHIR server being tested --></metadata> <action> <!-- 1..* A test operation or assert to perform --> <operation><!-- 0..1 Content as for TestScript.setup.action.operation The setup operation to perform --></operation> <assert><!-- 0..1 Content as for TestScript.setup.action.assert The setup assertion to perform --></assert> </action> </test> <teardown> <!-- 0..1 A series of required clean up steps --> <action> <!-- 1..* One or more teardown operations to perform --> <operation><!-- 0..1 Content as for TestScript.setup.action.operation The teardown operation to perform --></operation> </action> </teardown> </TestScript>
JSON Template
{
"resourceType" : "TestScript",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"url" : "<uri>", // R! Absolute URL used to reference this TestScript
"version" : "<string>", // Logical id for this version of the TestScript
"name" : "<string>", // R! Informal name for this TestScript
"status" : "<code>", // R! draft | active | retired
"identifier" : { Identifier }, // External identifier
"experimental" : <boolean>, // If for testing purposes, not real usage
"publisher" : "<string>", // Name of the publisher (Organization or individual)
"contact" : [{ // Contact details of the publisher
"name" : "<string>", // Name of an individual to contact
"telecom" : [{ ContactPoint }] // Contact details for individual or publisher
}],
"date" : "<dateTime>", // Date for this version of the TestScript
"description" : "<string>", // Natural language description of the TestScript
"useContext" : [{ CodeableConcept }], // Content intends to support these contexts
"requirements" : "<string>", // Scope and Usage this Test Script is for
"copyright" : "<string>", // Use and/or publishing restrictions
"origin" : [{ // An abstract server representing a client or sender in a message exchange
"index" : <integer>, // R! The index of the abstract origin server starting at 1
"profile" : { Coding } // R! FHIR-Client | FHIR-SDC-FormFiller
}],
"destination" : [{ // An abstract server representing a destination or receiver in a message exchange
"index" : <integer>, // R! The index of the abstract destination server starting at 1
"profile" : { Coding } // R! FHIR-Server | FHIR-SDC-FormManager | FHIR-SDC-FormReceiver | FHIR-SDC-FormProcessor
}],
"metadata" : { // Required capability that is assumed to function correctly on the FHIR server being tested
"link" : [{ // Links to the FHIR specification
"url" : "<uri>", // R! URL to the specification
"description" : "<string>" // Short description
}],
"capability" : [{ // R! Capabilities that are assumed to function correctly on the FHIR server being tested
"required" : <boolean>, // Are the capabilities required?
"validated" : <boolean>, // Are the capabilities validated?
"description" : "<string>", // The expected capabilities of the server
"origin" : [<integer>], // Which origin server these requirements apply to
"destination" : <integer>, // Which server these requirements apply to
"link" : ["<uri>"], // Links to the FHIR specification
"conformance" : { Reference(Conformance) } // R! Required Conformance
}]
},
"fixture" : [{ // Fixture in the test script - by reference (uri)
"autocreate" : <boolean>, // Whether or not to implicitly create the fixture during setup
"autodelete" : <boolean>, // Whether or not to implicitly delete the fixture during teardown
"resource" : { Reference(Any) } // Reference of the resource
}],
"profile" : [{ Reference(Any) }], // Reference of the validation profile
"variable" : [{ // Placeholder for evaluated elements
"name" : "<string>", // R! Descriptive name for this variable
"defaultValue" : "<string>", // Default, hard-coded, or user-defined value for this variable
"headerField" : "<string>", // HTTP header field name for source
"path" : "<string>", // XPath or JSONPath against the fixture body
"sourceId" : "<id>" // Fixture Id of source expression or headerField within this variable
}],
"rule" : [{ // Assert rule used within the test script
"resource" : { Reference(Any) }, // R! Assert rule resource reference
"param" : [{ // Rule parameter template
"name" : "<string>", // R! Parameter name matching external assert rule parameter
"value" : "<string>" // Parameter value defined either explicitly or dynamically
}]
}],
"ruleset" : [{ // Assert ruleset used within the test script
"resource" : { Reference(Any) }, // R! Assert ruleset resource reference
"rule" : [{ // R! Id of referenced rule within the ruleset
"param" : [{ // Ruleset rule parameter template
"name" : "<string>", // R! Parameter name matching external assert ruleset rule parameter
"value" : "<string>" // Parameter value defined either explicitly or dynamically
}]
}]
}],
"setup" : { // A series of required setup operations before tests are executed
"metadata" : { Content as for TestScript.metadata }, // Capabilities that are assumed to function correctly on the FHIR server being tested
"action" : [{ // R! A setup operation or assert to perform
"operation" : { // The setup operation to perform
"type" : { Coding }, // The operation code type that will be executed
"resource" : "<code>", // Resource type
"label" : "<string>", // Tracking/logging operation label
"description" : "<string>", // Tracking/reporting operation description
"accept" : "<code>", // xml | json
"contentType" : "<code>", // xml | json
"destination" : <integer>, // Server responding to the request
"encodeRequestUrl" : <boolean>, // Whether or not to send the request url in encoded format
"origin" : <integer>, // Server initiating the request
"params" : "<string>", // Explicitly defined path parameters
"requestHeader" : [{ // Each operation can have one ore more header elements
"field" : "<string>", // R! HTTP header field name
"value" : "<string>" // R! HTTP headerfield value
}],
"responseId" : "<id>", // Fixture Id of mapped response
"sourceId" : "<id>", // Fixture Id of body for PUT and POST requests
"targetId" : "<id>", // Id of fixture used for extracting the [id], [type], and [vid] for GET requests
"url" : "<string>" // Request URL
},
"assert" : { // The assertion to perform
"label" : "<string>", // Tracking/logging assertion label
"description" : "<string>", // Tracking/reporting assertion description
"direction" : "<code>", // response | request
"compareToSourceId" : "<string>", // Id of fixture used to compare the "sourceId/path" evaluations to
"compareToSourcePath" : "<string>", // XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to
"contentType" : "<code>", // xml | json
"headerField" : "<string>", // HTTP header field name
"minimumId" : "<string>", // Fixture Id of minimum content resource
"navigationLinks" : <boolean>, // Perform validation on navigation links?
"operator" : "<code>", // equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains
"path" : "<string>", // XPath or JSONPath expression
"resource" : "<code>", // Resource type
"response" : "<code>", // okay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessable
"responseCode" : "<string>", // HTTP response code to test
"rule" : { // Id of the TestScript.rule
"param" : [{ // Rule parameter template
"name" : "<string>", // R! Parameter name matching external assert rule parameter
"value" : "<string>" // R! Parameter value defined either explicitly or dynamically
}]
},
"ruleset" : { // Id of the TestScript.ruleset
"rule" : [{ // R! Id of referenced rule within the ruleset
"param" : [{ // Rule parameter template
"name" : "<string>", // R! Parameter name matching external assert ruleset rule parameter
"value" : "<string>" // R! Parameter value defined either explicitly or dynamically
}]
}]
},
"sourceId" : "<id>", // Fixture Id of source expression or headerField
"validateProfileId" : "<id>", // Profile Id of validation profile reference
"value" : "<string>", // The value to compare to
"warningOnly" : <boolean> // Will this assert produce a warning only on error?
}
}]
},
"test" : [{ // A test in this script
"name" : "<string>", // Tracking/logging name of this test
"description" : "<string>", // Tracking/reporting short description of the test
"metadata" : { Content as for TestScript.metadata }, // Capabilities that are expected to function correctly on the FHIR server being tested
"action" : [{ // R! A test operation or assert to perform
"operation" : { Content as for TestScript.setup.action.operation }, // The setup operation to perform
"assert" : { Content as for TestScript.setup.action.assert } // The setup assertion to perform
}]
}],
"teardown" : { // A series of required clean up steps
"action" : [{ // R! One or more teardown operations to perform
"operation" : { Content as for TestScript.setup.action.operation } // The teardown operation to perform
}]
}
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| TestScript | DomainResource | Describes a set of tests | ||
| url | Σ | 1..1 | uri | Absolute URL used to reference this TestScript |
| version | Σ | 0..1 | string | Logical id for this version of the TestScript |
| name | Σ | 1..1 | string | Informal name for this TestScript |
| status | ?! Σ | 1..1 | code | draft | active | retired ConformanceResourceStatus (Required) |
| identifier | Σ | 0..1 | Identifier | External identifier |
| experimental | Σ | 0..1 | boolean | If for testing purposes, not real usage |
| publisher | Σ | 0..1 | string | Name of the publisher (Organization or individual) |
| contact | Σ | 0..* | BackboneElement | Contact details of the publisher |
| name | Σ | 0..1 | string | Name of an individual to contact |
| telecom | Σ | 0..* | ContactPoint | Contact details for individual or publisher |
| date | Σ | 0..1 | dateTime | Date for this version of the TestScript |
| description | Σ | 0..1 | string | Natural language description of the TestScript |
| useContext | Σ | 0..* | CodeableConcept | Content intends to support these contexts Context of Use ValueSet (Extensible) |
| requirements | 0..1 | string | Scope and Usage this Test Script is for | |
| copyright | 0..1 | string | Use and/or publishing restrictions | |
| origin | 0..* | BackboneElement | An abstract server representing a client or sender in a message exchange | |
| index | 1..1 | integer | The index of the abstract origin server starting at 1 | |
| profile | 1..1 | Coding | FHIR-Client | FHIR-SDC-FormFiller TestScriptProfileOriginType (Extensible) | |
| destination | 0..* | BackboneElement | An abstract server representing a destination or receiver in a message exchange | |
| index | 1..1 | integer | The index of the abstract destination server starting at 1 | |
| profile | 1..1 | Coding | FHIR-Server | FHIR-SDC-FormManager | FHIR-SDC-FormReceiver | FHIR-SDC-FormProcessor TestScriptProfileDestinationType (Extensible) | |
| metadata | I | 0..1 | BackboneElement | Required capability that is assumed to function correctly on the FHIR server being tested TestScript metadata capability SHALL contain required or validated or both. |
| link | 0..* | BackboneElement | Links to the FHIR specification | |
| url | 1..1 | uri | URL to the specification | |
| description | 0..1 | string | Short description | |
| capability | 1..* | BackboneElement | Capabilities that are assumed to function correctly on the FHIR server being tested | |
| required | 0..1 | boolean | Are the capabilities required? | |
| validated | 0..1 | boolean | Are the capabilities validated? | |
| description | 0..1 | string | The expected capabilities of the server | |
| origin | 0..* | integer | Which origin server these requirements apply to | |
| destination | 0..1 | integer | Which server these requirements apply to | |
| link | 0..* | uri | Links to the FHIR specification | |
| conformance | 1..1 | Reference(Conformance) | Required Conformance | |
| fixture | 0..* | BackboneElement | Fixture in the test script - by reference (uri) | |
| autocreate | 0..1 | boolean | Whether or not to implicitly create the fixture during setup | |
| autodelete | 0..1 | boolean | Whether or not to implicitly delete the fixture during teardown | |
| resource | 0..1 | Reference(Any) | Reference of the resource | |
| profile | 0..* | Reference(Any) | Reference of the validation profile | |
| variable | I | 0..* | BackboneElement | Placeholder for evaluated elements Variable cannot contain both headerField and path. |
| name | 1..1 | string | Descriptive name for this variable | |
| defaultValue | 0..1 | string | Default, hard-coded, or user-defined value for this variable | |
| headerField | 0..1 | string | HTTP header field name for source | |
| path | 0..1 | string | XPath or JSONPath against the fixture body | |
| sourceId | 0..1 | id | Fixture Id of source expression or headerField within this variable | |
| rule | 0..* | BackboneElement | Assert rule used within the test script | |
| resource | 1..1 | Reference(Any) | Assert rule resource reference | |
| param | 0..* | BackboneElement | Rule parameter template | |
| name | 1..1 | string | Parameter name matching external assert rule parameter | |
| value | 0..1 | string | Parameter value defined either explicitly or dynamically | |
| ruleset | 0..* | BackboneElement | Assert ruleset used within the test script | |
| resource | 1..1 | Reference(Any) | Assert ruleset resource reference | |
| rule | 1..* | BackboneElement | Id of referenced rule within the ruleset | |
| param | 0..* | BackboneElement | Ruleset rule parameter template | |
| name | 1..1 | string | Parameter name matching external assert ruleset rule parameter | |
| value | 0..1 | string | Parameter value defined either explicitly or dynamically | |
| setup | 0..1 | BackboneElement | A series of required setup operations before tests are executed | |
| metadata | I | 0..1 | see metadata | Capabilities that are assumed to function correctly on the FHIR server being tested Setup metadata capability SHALL contain required or validated or both. |
| action | I | 1..* | BackboneElement | A setup operation or assert to perform Setup action SHALL contain either an operation or assert but not both. |
| operation | I | 0..1 | BackboneElement | The setup operation to perform Setup operation SHALL contain either sourceId or targetId or params or url. |
| type | 0..1 | Coding | The operation code type that will be executed TestScriptOperationCode (Extensible) | |
| resource | 0..1 | code | Resource type FHIRDefinedType (Required) | |
| label | 0..1 | string | Tracking/logging operation label | |
| description | 0..1 | string | Tracking/reporting operation description | |
| accept | 0..1 | code | xml | json ContentType (Required) | |
| contentType | 0..1 | code | xml | json ContentType (Required) | |
| destination | 0..1 | integer | Server responding to the request | |
| encodeRequestUrl | 0..1 | boolean | Whether or not to send the request url in encoded format | |
| origin | 0..1 | integer | Server initiating the request | |
| params | 0..1 | string | Explicitly defined path parameters | |
| requestHeader | 0..* | BackboneElement | Each operation can have one ore more header elements | |
| field | 1..1 | string | HTTP header field name | |
| value | 1..1 | string | HTTP headerfield value | |
| responseId | 0..1 | id | Fixture Id of mapped response | |
| sourceId | 0..1 | id | Fixture Id of body for PUT and POST requests | |
| targetId | 0..1 | id | Id of fixture used for extracting the [id], [type], and [vid] for GET requests | |
| url | 0..1 | string | Request URL | |
| assert | I | 0..1 | BackboneElement | The assertion to perform Setup action assert shall contain both compareToSourceId and compareToSourcePath or neither. Only a single assertion SHALL be present within setup action assert element. |
| label | 0..1 | string | Tracking/logging assertion label | |
| description | 0..1 | string | Tracking/reporting assertion description | |
| direction | 0..1 | code | response | request AssertionDirectionType (Required) | |
| compareToSourceId | 0..1 | string | Id of fixture used to compare the "sourceId/path" evaluations to | |
| compareToSourcePath | 0..1 | string | XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to | |
| contentType | 0..1 | code | xml | json ContentType (Required) | |
| headerField | 0..1 | string | HTTP header field name | |
| minimumId | 0..1 | string | Fixture Id of minimum content resource | |
| navigationLinks | 0..1 | boolean | Perform validation on navigation links? | |
| operator | 0..1 | code | equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains AssertionOperatorType (Required) | |
| path | 0..1 | string | XPath or JSONPath expression | |
| resource | 0..1 | code | Resource type FHIRDefinedType (Required) | |
| response | 0..1 | code | okay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessable AssertionResponseTypes (Required) | |
| responseCode | 0..1 | string | HTTP response code to test | |
| rule | 0..1 | BackboneElement | Id of the TestScript.rule | |
| param | 0..* | BackboneElement | Rule parameter template | |
| name | 1..1 | string | Parameter name matching external assert rule parameter | |
| value | 1..1 | string | Parameter value defined either explicitly or dynamically | |
| ruleset | 0..1 | BackboneElement | Id of the TestScript.ruleset | |
| rule | 1..* | BackboneElement | Id of referenced rule within the ruleset | |
| param | 0..* | BackboneElement | Rule parameter template | |
| name | 1..1 | string | Parameter name matching external assert ruleset rule parameter | |
| value | 1..1 | string | Parameter value defined either explicitly or dynamically | |
| sourceId | 0..1 | id | Fixture Id of source expression or headerField | |
| validateProfileId | 0..1 | id | Profile Id of validation profile reference | |
| value | 0..1 | string | The value to compare to | |
| warningOnly | 0..1 | boolean | Will this assert produce a warning only on error? | |
| test | 0..* | BackboneElement | A test in this script | |
| name | 0..1 | string | Tracking/logging name of this test | |
| description | 0..1 | string | Tracking/reporting short description of the test | |
| metadata | I | 0..1 | see metadata | Capabilities that are expected to function correctly on the FHIR server being tested Test metadata capability SHALL contain required or validated or both. |
| action | I | 1..* | BackboneElement | A test operation or assert to perform Test action SHALL contain either an operation or assert but not both. |
| operation | I | 0..1 | see operation | The setup operation to perform Test operation SHALL contain either sourceId or targetId or params or url. |
| assert | I | 0..1 | see assert | The setup assertion to perform Test action assert shall contain both compareToSourceId and compareToSourcePath or neither. Only a single assertion SHALL be present within test action assert element. |
| teardown | 0..1 | BackboneElement | A series of required clean up steps | |
| action | I | 1..* | BackboneElement | One or more teardown operations to perform Teardown action SHALL contain an operation. |
| operation | I | 0..1 | see operation | The teardown operation to perform Teardown operation SHALL contain either sourceId or targetId or params or url. |
| Documentation for this format | ||||
XML Template
<TestScript xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "TestScript",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"url" : "<uri>", // R! Absolute URL used to reference this TestScript
"version" : "<string>", // Logical id for this version of the TestScript
"name" : "<string>", // R! Informal name for this TestScript
"status" : "<code>", // R! draft | active | retired
"identifier" : { Identifier }, // External identifier
"experimental" : <boolean>, // If for testing purposes, not real usage
"publisher" : "<string>", // Name of the publisher (Organization or individual)
"contact" : [{ // Contact details of the publisher
"name" : "<string>", // Name of an individual to contact
"telecom" : [{ ContactPoint }] // Contact details for individual or publisher
}],
"date" : "<dateTime>", // Date for this version of the TestScript
"description" : "<string>", // Natural language description of the TestScript
"useContext" : [{ CodeableConcept }], // Content intends to support these contexts
"requirements" : "<string>", // Scope and Usage this Test Script is for
"copyright" : "<string>", // Use and/or publishing restrictions
"origin" : [{ // An abstract server representing a client or sender in a message exchange
"index" : <integer>, // R! The index of the abstract origin server starting at 1
"profile" : { Coding } // R! FHIR-Client | FHIR-SDC-FormFiller
}],
"destination" : [{ // An abstract server representing a destination or receiver in a message exchange
"index" : <integer>, // R! The index of the abstract destination server starting at 1
"profile" : { Coding } // R! FHIR-Server | FHIR-SDC-FormManager | FHIR-SDC-FormReceiver | FHIR-SDC-FormProcessor
}],
"metadata" : { // Required capability that is assumed to function correctly on the FHIR server being tested
"link" : [{ // Links to the FHIR specification
"url" : "<uri>", // R! URL to the specification
"description" : "<string>" // Short description
}],
"capability" : [{ // R! Capabilities that are assumed to function correctly on the FHIR server being tested
"required" : <boolean>, // Are the capabilities required?
"validated" : <boolean>, // Are the capabilities validated?
"description" : "<string>", // The expected capabilities of the server
"origin" : [<integer>], // Which origin server these requirements apply to
"destination" : <integer>, // Which server these requirements apply to
"link" : ["<uri>"], // Links to the FHIR specification
"conformance" : { Reference(Conformance) } // R! Required Conformance
}]
},
"fixture" : [{ // Fixture in the test script - by reference (uri)
"autocreate" : <boolean>, // Whether or not to implicitly create the fixture during setup
"autodelete" : <boolean>, // Whether or not to implicitly delete the fixture during teardown
"resource" : { Reference(Any) } // Reference of the resource
}],
"profile" : [{ Reference(Any) }], // Reference of the validation profile
"variable" : [{ // Placeholder for evaluated elements
"name" : "<string>", // R! Descriptive name for this variable
"defaultValue" : "<string>", // Default, hard-coded, or user-defined value for this variable
"headerField" : "<string>", // HTTP header field name for source
"path" : "<string>", // XPath or JSONPath against the fixture body
"sourceId" : "<id>" // Fixture Id of source expression or headerField within this variable
}],
"rule" : [{ // Assert rule used within the test script
"resource" : { Reference(Any) }, // R! Assert rule resource reference
"param" : [{ // Rule parameter template
"name" : "<string>", // R! Parameter name matching external assert rule parameter
"value" : "<string>" // Parameter value defined either explicitly or dynamically
}]
}],
"ruleset" : [{ // Assert ruleset used within the test script
"resource" : { Reference(Any) }, // R! Assert ruleset resource reference
"rule" : [{ // R! Id of referenced rule within the ruleset
"param" : [{ // Ruleset rule parameter template
"name" : "<string>", // R! Parameter name matching external assert ruleset rule parameter
"value" : "<string>" // Parameter value defined either explicitly or dynamically
}]
}]
}],
"setup" : { // A series of required setup operations before tests are executed
"metadata" : { Content as for TestScript.metadata }, // Capabilities that are assumed to function correctly on the FHIR server being tested
"action" : [{ // R! A setup operation or assert to perform
"operation" : { // The setup operation to perform
"type" : { Coding }, // The operation code type that will be executed
"resource" : "<code>", // Resource type
"label" : "<string>", // Tracking/logging operation label
"description" : "<string>", // Tracking/reporting operation description
"accept" : "<code>", // xml | json
"contentType" : "<code>", // xml | json
"destination" : <integer>, // Server responding to the request
"encodeRequestUrl" : <boolean>, // Whether or not to send the request url in encoded format
"origin" : <integer>, // Server initiating the request
"params" : "<string>", // Explicitly defined path parameters
"requestHeader" : [{ // Each operation can have one ore more header elements
"field" : "<string>", // R! HTTP header field name
"value" : "<string>" // R! HTTP headerfield value
}],
"responseId" : "<id>", // Fixture Id of mapped response
"sourceId" : "<id>", // Fixture Id of body for PUT and POST requests
"targetId" : "<id>", // Id of fixture used for extracting the [id], [type], and [vid] for GET requests
"url" : "<string>" // Request URL
},
"assert" : { // The assertion to perform
"label" : "<string>", // Tracking/logging assertion label
"description" : "<string>", // Tracking/reporting assertion description
"direction" : "<code>", // response | request
"compareToSourceId" : "<string>", // Id of fixture used to compare the "sourceId/path" evaluations to
"compareToSourcePath" : "<string>", // XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to
"contentType" : "<code>", // xml | json
"headerField" : "<string>", // HTTP header field name
"minimumId" : "<string>", // Fixture Id of minimum content resource
"navigationLinks" : <boolean>, // Perform validation on navigation links?
"operator" : "<code>", // equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains
"path" : "<string>", // XPath or JSONPath expression
"resource" : "<code>", // Resource type
"response" : "<code>", // okay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessable
"responseCode" : "<string>", // HTTP response code to test
"rule" : { // Id of the TestScript.rule
"param" : [{ // Rule parameter template
"name" : "<string>", // R! Parameter name matching external assert rule parameter
"value" : "<string>" // R! Parameter value defined either explicitly or dynamically
}]
},
"ruleset" : { // Id of the TestScript.ruleset
"rule" : [{ // R! Id of referenced rule within the ruleset
"param" : [{ // Rule parameter template
"name" : "<string>", // R! Parameter name matching external assert ruleset rule parameter
"value" : "<string>" // R! Parameter value defined either explicitly or dynamically
}]
}]
},
"sourceId" : "<id>", // Fixture Id of source expression or headerField
"validateProfileId" : "<id>", // Profile Id of validation profile reference
"value" : "<string>", // The value to compare to
"warningOnly" : <boolean> // Will this assert produce a warning only on error?
}
}]
},
"test" : [{ // A test in this script
"name" : "<string>", // Tracking/logging name of this test
"description" : "<string>", // Tracking/reporting short description of the test
"metadata" : { Content as for TestScript.metadata }, // Capabilities that are expected to function correctly on the FHIR server being tested
"action" : [{ // R! A test operation or assert to perform
"operation" : { Content as for TestScript.setup.action.operation }, // The setup operation to perform
"assert" : { Content as for TestScript.setup.action.assert } // The setup assertion to perform
}]
}],
"teardown" : { // A series of required clean up steps
"action" : [{ // R! One or more teardown operations to perform
"operation" : { Content as for TestScript.setup.action.operation } // The teardown operation to perform
}]
}
}
Alternate definitions: Schema/Schematron, Resource Profile (XML, JSON), Questionnaire
| Path | Definition | Type | Reference |
|---|---|---|---|
| TestScript.status | The lifecycle status of a Value Set or Concept Map. | Required | ConformanceResourceStatus |
| TestScript.useContext | Indicates the countries, regions, disciplines and other aspects of use within which this artifact is targeted for use. | Extensible | Context of Use ValueSet |
| TestScript.origin.profile | The type of origin profile the test system supports. | Extensible | TestScriptProfileOriginType |
| TestScript.destination.profile | The type of destination profile the test system supports. | Extensible | TestScriptProfileDestinationType |
| TestScript.setup.action.operation.type | The allowable operation code types. | Extensible | TestScriptOperationCode |
| TestScript.setup.action.operation.resource TestScript.setup.action.assert.resource | Either a resource or a data type. | Required | http://hl7.org/fhir/valueset/defined-typesFHIRDefinedType |
| TestScript.setup.action.operation.accept TestScript.setup.action.operation.contentType TestScript.setup.action.assert.contentType | The content or mime type. | Required | ContentType |
| TestScript.setup.action.assert.direction | The type of direction to use for assertion. | Required | AssertionDirectionType |
| TestScript.setup.action.assert.operator | The type of operator to use for assertion. | Required | AssertionOperatorType |
| TestScript.setup.action.assert.response | The type of response code to use for assertion. | Required | AssertionResponseTypes |
To test if create operation is properly supported on a server, run the operation as part of TestScript.test.
First, define the fixture as a reference at the top of the test script. The fixture will hold the body of the POST request:
Note that it is illegal for the fixture to contain a resource id in a create operation.
Point the sourceId element of the create operation to the fixture id just defined:
There are two ways to verify that the create operation returned the right status code:
Use assert.response:
Use assert.responseCode explicitly:
To test if search operation is properly supported on a server, run the operation as part of TestScript.test.
Use the resource element to specify the resource type and the params element to specify the search parameters:
The contentType element is optional and will default to "xml" which will translate to HTTP request header "Content-Type" being set to "application/xml+fhir" by test engines. In this case, though, it was used to set it to "application/json+fhir".
The responseId element was used to store the response in a reference called "R1". This reference will hold both the response headers and the response body.
Verify that the search operation returned the right status code:
See response codes for complete list.
Verify that the search operation returned the right resource type:
There are many ways to verify that the search operation returned the right Patient:
Explicitly compare the elements to known value:
The sourceId element is pointed to the responseId value of the search operation. If no sourceId is specified, then test engines will use the response of the last operation in the test script even if responseId was not specified in the operation.
The path element holds an XPath or JSONPath expression against the response body contents.
Compare the elements in response to elements in another fixture that is either dynamically set by responseId or defined statically by the fixture element at the top of the script:
This time the birthDate value in the response is compared to the birthDate value in a fixture called 'F1'.
Verify that the response contains all the element/content in another fixture pointed to by minimumId.
Test engines will parse the 'body' of the F1 fixture and verify that each element and its value matches the corresponding element in the R1 response body. In other words, R1 is verified to be a 'superset' of F1. The resource id element in the body will be ignored during comparison. The headers will also be ignored.
F1 can be statically defined or it can be the responseId for another operation. If sourceId is not specified, then test engines will use the response of the last operation. So the previous assertion could have been defined as:
Test scripts should clean up resources created as part of execution. The TestScript.teardown operations will get executed once before the test script execution completes.
Here are a couple of ways to run delete operation in TestScript.teardown:
Use delete operation with targetId fixture.
To do that, the resource must have been created during TestScript.setup or TestScript.test:
As part of TestScript.teardown, run the delete operation with targetId value pointed to sourceId value of the create operation:
Test engines will keep track of response headers and body of all operations.
The delete operation's targetId value is expected to correspond to the responseId of a GET operation (such as search or read) or the sourceId of a POST/PUT operation (such as create).
For targetId value corresponding to responseId of GET operations (such as search or read), test engines will use the resource type and id returned in the GET response body's resource to set the [type] and [id] in delete operation's URL, respectively.
For targetId value corresponding to responseId of POST/PUT operations (such as create), test engines will use the resource type and id returned in the POST/PUT response "Location" header to set the [type] and [id] in delete operation's URL, respectively. This is the case in the example above.
The targetId value cannot point to a statically defined fixture as the id in the fixture cannot be relied upon.
Deletion of resources created during test script execution should be done using delete operation in TestScript.teardown. See Perform delete operation in teardown for details.
There might be left-over resource instances though on the server from prior executions of the script that terminated prematurely through an error. Resources can be deleted in TestScript.setup as well to ensure reliable test execution.
To delete a resource in setup, the server is required to support Conditional Delete operation.
Use the params element to specify the search criteria for the delete operation:
Test engines will append the contents of the params element to url after [type]: "[base]/[type]?[search parameters]". The resource element value ("Patient") will be used to replace [type] in the url.
To test if a server supports conditional delete operation, run a create operation prior to the delete using a sourceId that points to a fixture defined at the top of the script:
Then use the params element to specify the search criteria for the delete operation:
Test engines will append the contents of the params element to url after [type]: "[base]/[type]?[search parameters]". The resource element value ("Patient") will be used to replace [type] in the url.
To verify that the delete operation returned the right status code:
To verify that the resource was indeed deleted on the server, run a search using the same parameters and verify that the status code is 404 (not found):
To test if a server supports conditional create operation, use the 'If-None-Exist' request header:
The response code of 200 verifies that the resource already exists and did not get created:
Update operations require a resource id. The id must be present in the fixture (PUT body contents) as well as the URL. The values must match.
Because resource ids cannot be predicted on the server, it is best to retrieve the id on a resource freshly created as part of the script
There are many ways to do that. Below is a couple:
Use update operation with targetId fixture pointing to create operation's responseId:
Test engines will keep track of response headers and body of all operations.
The update operation's targetId value is expected to correspond to the responseId of a GET operation (such as search or read) or the sourceId of a POST/PUT operation (such as create).
For targetId value corresponding to responseId of GET operations (such as search or read), test engines will use the resource type and id returned in the GET response body's resource to set the [type] and [id] in update operation's URL, respectively. This is the case in the next example below.
For targetId value corresponding to responseId of POST/PUT operations (such as create and update), test engines will use the resource type and id returned in the POST/PUT response "Location" header to set the [type] and [id] in update operation's URL, respectively. This is the case in the example above.
The targetId value cannot point to a statically defined fixture as the id in the fixture cannot be relied upon.
Use update operation with targetId fixture pointing to search operation's responseId:
After the update operation, test scripts would perform at least one more read/search operation to retrieve the contents of the updated resource and then perform assertions to verify that the data did indeed get updated on the server:
Verify that the birthdate got updated and is being returned properly:
Unlike a regular update operation, a conditional update operation does not require a resource id in the URL (or the body of the PUT).
To test conditional update, use params element in the operation instead of targetId. The resource element will be required in this case.
Test engines will append the contents of the params element to url after [type]: "PUT [base]/[type]?[search parameters]". The resource element value ("Patient") will be used to replace [type] in the URL.
Verify that the birthdate got updated and is being returned properly:
The read operation operation requires the resource id in the URL. Since resource ids are unpredictable on servers, it's best to create the resource within the test script prior to executing the read operation:
One way to execute the read operation is to run the read operation with targetId value pointed to responseId value of the create operation:
Test engines will keep track of response headers and body of all operations.
The read operation's targetId value is expected to correspond to the responseId of a GET operation (such as search or read) or the sourceId of a POST/PUT operation (such as create).
For targetId value corresponding to responseId of GET operations (such as search or read), test engines will use the resource type and id returned in the GET response body's resource to set the [type] and [id] in read operation's URL, respectively.
For targetId value corresponding to responseId of POST/PUT operations (such as create), test engines will use the resource type and id returned in the POST/PUT response "Location" header to set the [type] and [id] in read operation's URL, respectively. This is the case in the example above.
The targetId value cannot point to a statically defined fixture as the id in the fixture cannot be relied upon.
The vread operation operation requires the resource id as well as the resource version id in the URL. Since resource ids and version ids are unpredictable on servers, it's best to create the resource within the test script prior to executing the vread operation:
One way to execute the vread operation is to run the vread operation with targetId value pointed to responseId value of the create operation:
Test engines will keep track of response headers and body of all operations.
The vread operation's targetId value is expected to correspond to the responseId of a GET operation (such as search or read) or the sourceId of a POST/PUT operation (such as create).
For targetId value corresponding to responseId of GET operations (such as search or read), test engines will use the resource type, id and version id returned in the GET response body's resource to set the [type], [id] and [vid] in vread operation's URL, respectively.
For targetId value corresponding to responseId of POST/PUT operations (such as create), test engines will use the resource type, id and version id returned in the POST/PUT response "Location" header to set the [type], [id] and [vid] in vread operation's URL, respectively. This is the case in the example above.
The targetId value cannot point to a statically defined fixture as the id in the fixture cannot be relied upon.
The history operation can be executed in the following ways:
GET [base]/[type]/[id]/_history{?[parameters]&_format=[mime-type]}
Here the resource id is required in the URL. This is similar to read operation if targetId elemet is used. See Test read operation for details.
Here the resource id is not required in the URL.
Instead of targetId element, the params element can be used to specify the search criteria for the history operation.
In the following example, all history entries for John Doe patient would be returned by server:
Here neither the resource type nor the resource id is required in the url. In the following example, no more than 50 history entries would be returned by server:
The default "Accept" header that will be set on all GET operations (such as read, vread, search, history, etc.) will be "application/xml+fhir".
There are two ways to change the default "Accept" header:
Use the accept element:
Test engines will set the Accept header to "application/json+fhir" if "json" is specified and will use "application/xml+fhir" if "xml" is specified.
Use the requestHeader element to set "Accept" explicitly:
Test engines will take values specified for requestHeader "as-is" and not transform them. This might be useful for negative testing e.g. the value can be set explicitly to "applcation/xml" or an invalid value and verify server response.
The default "Content-Type" header that will be set on all POST/PUT operations (such as create, update, etc.) will be "application/xml+fhir".
There are two ways to change the default "Content-Type" header:
Use the contentType element:
Test engines will set the Content-Type header to "application/json+fhir" if "json" is specified and will use "application/xml+fhir" if "xml" is specified.
Use the requestHeader element to set Content-Type explicitly:
Test engines will take values specified for requestHeader "as-is" and not transform them. This might be useful for negative testing e.g. the value can be set explicitly to "applcation/xml" or an invalid value and verify server response.
There are two ways to verify the "Content-Type" header in response:
Use the contentType element:
Test engines will verify that "application/json+fhir" is present in Content-Type header if "json" is specified and will verify that "application/xml+fhir" is present if "xml" is specified.
Use the requestHeader element to verify Content-Type explicitly:
Test engines will take values specified for headerField "as-is" and not interpret them.
Note that test engines will not verify contentType in response if assertions for contentType are missing.
Variables can be defined against static fixtures and dynamic operation responses. They can be used in "operation.params", "operation.requestHeader.value", "operation.url", and "assert.value" element values. As such they allow for the data used in operations and assertions to be externally defined. The data could be unique to each client involved in interactions with a server or could be unique to a given server database instance. This allows for multiple clients to execute the same test scripts concurrently against the same server.
Variables would be defined at the top of the script.
Below is a variable that is defined as the Location header to the response referenced by "R1":
Test engines will not evaluate this at this point. They will store the expresssion in "V1" and will look for "${}" in "operation.params", "operation.requestHeader.value", and "operation.url" element values during operation calls.
Here is a read operation that will use the V1 variable. The variable expression was "Location against R1 response" (defined above). If a prior operation has not set R1 to be the responseId of the operation, then test engine will error out. Otherwise, V1 will be set to the Location header value of R1 response and that value will be substituted for ${V1} below. In other words, the read will be performed against the Location header value of R1 response.
Below are three variables defined as path expressions against the static fixture referenced by "F1". The expressions are against the given name, family name, and birthDate of a patient resource. The resource data will be managed external to the test script.
Again, test engines will not evaluate the path expression at this point. They will look for anything wrapped in '${}' in "operation.params", "operation.requestHeader.value", "operation.url", and "assert.value" element values and substitute the placeholders with the evaluated expressions.
Here is a conditional create operation that will set the requestHeader using the PatientGivenName, PatientFamilyName, and PatientDOB variables defined above. The variable expressions were path expressions against the statically defined F1 fixture. They will be evaluated against the fixture body (containing resource) and the corresponding values will be extracted from the fixtures and used to substitute the variables in the requestHeader value below.
Here is a search operation that will perform a search using the PatientGivenName, PatientFamilyName, and PatientDOB variables defined above. The variable expressions were path expressions against the statically defined F1 fixture. They will be evaluated against the fixture body (containing resource) and the corresponding values will be extracted from the fixtures and used to substitute the variables in the params value below.
Here are the assertions that verify that the search was successful:
Servers are required to support "_format" in the request url to determine the response mime-type. See Content Type and Encodings
Use the params element to specify the _format:
Use the requestHeader element to verify Content-Type explicitly:
If the capabilities are supported by the server, then the TestScript can be executed. Otherwise, the TestScript as a whole or a specific test within the test script may be skipped depending on where the capabilities section is defined.
Here's how to specify that the test script requires the server to support Patient create and delete operations:
The contents of PatientCreateDelete.xml would be a minimal conformance statement to indicate what sections need to be present in server conformance statement:
When the metadata capabilities section is defined at TestScript.metadata or at TestScript.setup.metadata, and the server's conformance statement does not contain the elements defined in the minimal conformance statement, then all the tests in the TestScript are skipped.
When the metadata capabilities section is defined at TestScript.test.metadata and the server's conformance statement does not contain the elements defined in the minimal conformance statement, then only that test is skipped.
The "metadata.capabilities.required" and "metadata.capabilities.validated" elements only indicate whether the capabilities are the primary focus of the test script or not. The do not impact the skipping logic. Capabilities whose "metadata.capabilities.validated" flag is true are the primary focus of the test script.
This table presents a summary of the constraints applicable to TestScript.setup.action.operation, TestScript.test.action.operation, and TestScript.teardown.action.operation elements. The operation elements should be configured consistently with the FHIR RESTful API summary.
| read | vread | search | history | create | update | transaction | conformance | delete | |
|---|---|---|---|---|---|---|---|---|---|
| params | The params element can be used to specify the [id] using variable substitutions and the rest of the highlighted portion in the request URL: [base]/[type]/[id] {?_format=[mime-type]} If used, then resource is required and targetId and url must not be specified. |
The params element can be used to specify the [id] and [vid] using variable substitutions and the rest of the highlighted portion in the request URL: [base]/[type]/[id]/_history/[vid] {?_format=[mime-type]} If used, then resource is required and targetId and url must not be specified. |
The params element can be used to specify the highlighted portion in the request URL: [base]/[type]{?[parameters]{&_format=[mime-type]}} If used, then resource is optional and targetId and url must not be specified. |
The params element can be used to specify the [id] using variable substitutions and the rest of the highlighted portion in the following request URLs: [base]/[type]/[id]/_history{?[parameters]&_format=[mime-type]} [base]/[type]/_history{?[parameters]&_format=[mime-type]} [base]/_history{?[parameters]&_format=[mime-type]} If used, then resource is optional and targetId and url must not be specified. |
N/A | The params element can be used in conditional update operation to specify the highlighted portion of the request URL: [base]/[type]?[search parameters] If used, then resource is required and targetId and url must not be specified. |
N/A | The params element can be used to specify the highlighted portion in the request URL: [base]/metadata {?_format=[mime-type]} If used, then resource is ignored and targetId and url must not be specified. |
The params element can be used to specify the [id] using variable substitutions in the request URL: [base]/[type]/[id] If used, then resource is required and targetId and url must not be specified. |
| resource | The resource element is required to specify the resource ([type]) in the request URL when params element is used. Will be ignored if targetId or url are specified. In the case of targetId, the resource type will be extracted from the fixture. | If targetId is specified, then [type] for request URL will be determined from targetId's fixture and resource element will be ignored. Otherwise, resource type will be extracted from sourceId's fixture if specified. For conditional updates, resource is required. | N/A | N/A | If targetId is specified, then [type] for request URL will be determined from targetId and resource element will be ignored. For conditional deletes, resource is required. | ||||
| sourceId | N/A | N/A | N/A | N/A | The sourceId element points to a fixture to be used for the created resource. The fixture cannot contain the id element. | The sourceId element points to a fixture to be used for the updated resource. Has to correspond to the responseId of an operation executed upstream in the test script. The response body must contain a resource with a resource id. The sourceId fixture cannot be statically defined because the id cannot be relied upon. | Fixture to be used for the transaction. Has to be a Bundle. | N/A | N/A |
| targetId | The targetId element can be used to specify the [type] and [id] in the request URL. If used, then params and url must not be specified. The targetId value has to correspond to the responseId of an operation executed upstream in the test script. The response body must contain a reosurce with a resource id. The targetId fixture cannot be statically defined because the id cannot be relied upon. |
The targetId element can be used to specify the [type], [id], and [vid] in the request URL. If used, then params and url must not be specified. The targetId value has to correspond to the responseId of an operation executed upstream in the test script. The response body must contain a reosurce with a resource id. The targetId fixture cannot be statically defined because the id and vid cannot be relied upon. |
The targetId element cannot be used as it's not allowed with params element | The targetId element can be used to specify the [type], [id], and [vid] in the request URL. If used, then params and url must not be specified. The targetId value has to correspond to the responseId of an operation executed upstream in the test script. The response body must contain a reosurce with a resource id. The targetId fixture cannot be statically defined because the id and vid cannot be relied upon. |
N/A. The [type] for the request URL will be extracted from sourceId. | N/A. The [type] for the request URL will be extracted from sourceId. | N/A. | N/A. | The targetId element can be used to specify the [type] and [id] in the request URL. If used, then params and url must not be specified. The targetId value has to correspond to the responseId of an operation executed upstream in the test script. The response body must contain a reosurce with a resource id. The targetId fixture cannot be statically defined because the id cannot be relied upon. |
| responseId | The responseId element can be used to reference the operation response containing response body and headers. If specified, the value can later be used in assertion sourceId to evaluate path (XPath/JSONPath) and headerFields against the response received for an operation. | N/A | |||||||
| accept | The accept element can be used to specify the "Accept" header in the outgoing HTTP request. If "json" is specified, then "Accept" value of "application/json+fhir" will be set in the request header. If "xml" is specified, then "application/xml+fhir" will be used. | N/A | |||||||
| contentType | The contentType element can be used to specify the "Content-Type" header in the outgoing HTTP request. If "json" is specified, then "Content-Type" value of "application/json+fhir" will be set in the request header. If "xml" is specified, then "application/xml+fhir" will be used. | N/A | |||||||
| requestHeader | The requestHeader element allows for request headers to be specified explicitly. Test engines will take values specified for requestHeader "as-is" and not transform them. This allows for testing using:
|
||||||||
| destination | If the TestScript is testing more than one FHIR server simultaneously, the destination identifies which server the operation applies to using zero-based indexing. | ||||||||
| url | The url element will contain the full HTTP URL for the operation. This should rarely be used in test scripts. One possible application would be to test if the Location header returned in a response is pointing to an expected resource. See testscript-search example. | ||||||||
| Assertion | Valid operator values | Description |
|---|---|---|
| contentType | equals | notEquals | contains | notContains | Asserts that the "Content-Type" in response header is or is not the specified value for contentType element depending on the operator used. |
| headerField | equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains | Asserts that the header specified for headerField element in the response contains, not contains, is equal, not equal, in, not in, greater than, or less than the value specified for value element if present. If the operator is "empty" or "notEmpty" then value will be ignored. If sourceId is not specified, then headerField will be evaluated against the last operation's response headers. |
| minimumId | N/A | Asserts that the response contains all the element/content in another fixture pointed to by minimumId element. This can be a statically defined fixture or one that is dynamically set via responseId. |
| navigationLinks | N/A | Asserts that the response Bundle contains or does NOT contain first, last, and next links depending on whether or not navigationLinks element is set to true or false. |
| path | equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains | Asserts that path against the response body evaluates to a value that contains, not contains, is equal, not equal, in, not in, greater than, or less than the value specified for value element if present. If the operator is "empty" or "notEmpty" then value will be ignored. If sourceId is not specified, then path will be evaluated against the last operation's response body. |
| compareToSourcePath | equals | notEquals | Asserts that compareToSourcePath against the response body of compareToSourceId fixture evaluates to a value that is equal or notEqual to the evaluated value of path which must be present also. |
| resource | equals | notEquals | Asserts that the resource returned in the response body is or is not of the specified value for resource element. |
| response | equals | notEquals | Asserts that status code in the response is or is not one of the enumerated values in response abbreviations. |
| responseCode | equals | notEquals | in | notIn | greaterThan | lessThan | Asserts that status code in the response is equal, notEqual, in, not in, greater than, or less than the specified value(s) for responseCode element |
| validateProfileId | N/A | Asserts that the response is valid according to the profile specified by validateProfileId element. |
Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.
| Name | Type | Description | Paths |
| description | string | Natural language description of the TestScript | TestScript.description |
| identifier | token | External identifier | TestScript.identifier |
| name | string | Informal name for this TestScript | TestScript.name |
| testscript-capability | string | TestScript required and validated capability | TestScript.metadata.capability.description |
| testscript-setup-capability | string | TestScript setup required and validated capability | TestScript.setup.metadata.capability.description |
| testscript-test-capability | string | TestScript test required and validated capability | TestScript.test.metadata.capability.description |
| url | uri | Absolute URL used to reference this TestScript | TestScript.url |
© HL7.org 2011+. FHIR STU3 Candidate (v1.4.0-8139) generated on Thu, Mar 31, 2016 08:10+1100. QA Page
Links: Search |
Version History |
Table of Contents |
Compare to DSTU2 |
|
Propose a change