Testplan Design Patterns

Testplan Design Patterns

Table of Contents

• Organization of Tests
• Basic transaction

Organization of Tests

Test, Section, Step

Basic transaction

The simplest testing role is to send a single transaction such as Provide and Register, we look at 11966 which is a Provide and Register to a Repository SUT. The test plan is:

<TestPlan>
  <Test>11966/submit</Test>
  <TestStep id="submit">
    <Goal>Transaction - Provide and Register to Repository under test
       Metadata pattern - Single Document submission
       Metadata contents - simple        Evaluation - Transaction is successful
    </Goal>
    <ExpectedStatus>Success</ExpectedStatus>
    <ProvideAndRegisterTransaction>
     <XDSb/>
     <MetadataFile>single_doc.xml</MetadataFile>
     <Document id="Document01">my_document.txt</Document>
    </ProvideAndRegisterTransaction>
  </TestStep>
</TestPlan>

<Test> identifies the test (as does the directory name holding test - they must be the same

<TestStep> is a Step which always holds a single transaction

<Goal> is documentation for the developer

<ExpectedStatus> indicates whether the transaction is expected to return an error.

<ProvideAndRegisterTransaction> tells us what transaction is sent. A TestStep must have a *Transaction element.

<XDSb/> indicates that the metadata template (listed under <MetadataFile/>) should be translated to XDS.b format. This is the default behavior now so this instruction is ignored. Originally when XDS.a and XDS.b were being tested this instruction allowed for the automatic transactions between version formats.

Now this TestStep is as simple as it gets but there is some automatic stuff going on behind the scenes. First the Orchestration phase almost always generates one or more Patient ID Reports. A Report is half of a Report/UseReport pair which is a Publish/Subscribe mechanism for sharing data between TestSteps. A TestStep reports a parameter/value pair. Another later TestStep uses the report. The UseReport statement identifies a Report of interest by specifying the Test/Section/Step/Name of the Report and assigning a local parameter name which can be coded in the Metadata template file.

Back to the Orchestration. It defines a Report named $patientid$ which is the default Patient ID for the test. This default is built into the processing of the metadata templates. If no further instructions are given, all Patient ID references will be updated to the value contained in $patientid$. Note that this only happens for ebRIM transactions with all the defaults in place. Other technologies will need a more manual approach. This automatic updating does not depend on the use of the $patientid$ variable. The test client knows the ebRIM structure and just does it.

After the transaction is run various details are published to the log file. The automatically assigned IDs come first:

<AssignedPatientId>
   <Assign
         symbol="Document01"
         id="P1219090236.2^^^&1.3.6.1.4.1.21367.13.20.1000&ISO"/>
   <Assign
         symbol="SubmissionSet01"
         id="P1219090236.2^^^&1.3.6.1.4.1.21367.13.20.1000&ISO"/>
</AssignedPatientId>
<AssignedUids>
   <Assign
         symbol="Document01"
         id="1.2.42.20181219090315.2"/>
   <Assign
         symbol="SubmissionSet01"
         id="1.2.42.20181219090315.3"/>
</AssignedUids>

In this example output taken from 11966 we see the UID and Patient ID values that were automatically assigned. Each ebRIM object is assigned a new unique UID allowing the transaction template to be reused. If these values are needed in a later TestStep then the <UseId> instruction is used. Note that UUIDs were not assigned by default. Most transaction templates are codes with symbolic values instead of UUIDs again so the templates can be reused. In this example the symbolic ID was sent in the actual transaction allowing the Registry to assign a real UUID. We could have had the UUID assigned by the test client. That will be shown later.

The same content is published using the Report/UseReport mechanism. The UseId mechanism is much older than Report and not as flexible. So that follow-on tests can be coded using the newer UseReport we include the Reports in the logs as well.

<Reports>
    <Report
          name="Document01_uid">1.2.42.20181219090315.2</Report>
    <Report
          name="SubmissionSet01_uid">1.2.42.20181219090315.3</Report>
    <Report
          name="$patientid$">P1219090236.2^^^&1.3.6.1.4.1.21367.13.20.1000&ISO</Report>
 </Reports>