Test collections and Conformance tool tabs

There are three parts to the Conformance tool tab configuration.

• Test plan collections.txt file
• ActorType Java enum class
• Tab configuration XML file

The Collections.txt file

The collections.txt file in a test definition tells which actor/profile/option(s) to link the test to. The annotations in collections.txt follow a strict naming convention. There are three parts to this convention. Actor, profile, and option. Actor is always required but the profile and option are optional. If they are excluded, profile will default to XDS, and option will default to Required.

The simplest collection is actor. This value must be lower-cased.

It means that a default profile (XDS) and option (Required) will be applied.

If a test plan targets a specific profile, such as the XCA-I, it should be appended with an open-parenthesis, profile string, and close-parenthesis to the actor like so:

actor(xca-i).

Omitting the option defaults to the Required option.

If a test plan targets a specific option, such as the XUA, it should be appended with an underscore to the actor like so:

actor_xua.

When both the profile and option need to be specified, use the following convention. For example:

actor(profile)_option.

ActorType

• Actor code is keyed off the ActorType#actorCode value. If this value is null, ActorType#shortName will be used instead. This value must match the collections.txt actor code. This value must be lower-cased.
• Profile is keyed off the ActorType#profile. This value must match the collections.txt profile code.
  • Only one profile can be specified for an ActorType. If the same actor is needed for multiple profiles, another ActorType may be used with the same ActorType#actorCode. (Unlike the actorCode, the ActorType#shortName should always be unique.)
• Option is keyed off the ActorType#options list. This value must match the collections.txt option code.

Tab configuration

Conformance test tool uses a three-tier menu system, with the Actor being the top-level, followed by Profile, and then Option. Each tab is represented by a Tab element. The top level tab must be an Actor. Next, the Profiles tab element is defined. There can be more than one profile tab. Finally the Option tab is nested under the Profile. There can be more than one option.

This user defined configuration is maintained in
${project_home}\xdstools2\src\main\webapp\toolkitx\tool-tab-configs\ConfTestsTabs.xml. Tab example:

<tab label="Repository" type="actor" tcCode="rep" displayColorCode="#D0E4F6">
   <tabs label="Profiles">
      <tab label="XDS" type="profile" tcCode="xds">
         <tabs label="Options">
            <tab label="Required"  type="option" tcCode="" externalStart="false"/>
            <tab label="XUA Option" type="option" tcCode="xua" externalStart="false"/> 
         </tabs>
      </tab>
   </tabs>
</tab>

In the above example, there is an actor tab with the label “Repository”, with the profile being “XDS” and two options: Required and XUA Option. The system uses the tcCode hierarchy to locate the matching test collections.

Multiple profiles per actor

If a separate simulator is needed to support another profile for the same actor, use the example configuration as shown below.

Tab configuration

<tab label="Document Source" type="actor" tcCode="src" displayColorCode="#D0E4F6">
   <tabs label="Profiles">
      <tab label="XDS" type="profile" tcCode="xds">
         <tabs label="Options">
            <tab label="Required"  type="option" tcCode="" externalStart="false"/>
         </tabs>
      </tab>
      <tab label="MHD" type="profile" tcCode="mhd">
         <tabs label="Options">
            <tab label="Required"  type="option" tcCode="" externalStart="false"/>
         </tabs>
      </tab>
   </tabs>
</tab>

Collections.txt

To map test plans to the XDS profile use: src(xds)

To map test plans to the MHD profile use: src(mhd)

ActorType.java pseudo code showing only the relevant fields

DOC_SOURCE_XDS(...,actorCode:="src",profile:="XDS",...)

DOC_SOURCE_MHD(...,actorCode:="src",profile:="MHD",...)

Notice how the actorCode is the same for both actors.

Unit test:

Xdstools2 module has a unit test ToolTabConfigVerifyTcCodesTest#'Verify if Tc codes in ToolTabConfig match values in ActorType' which can be run to verify if all codes are valid in the ConfTestsTabs.xml file. The xdstools2 Maven module declares in its POM.xml file a Java system property that is used to pass the file path to the tab configuration XML file in the Java src folder.

Sample output of the unit test is shown below.

Checking actor Registry... 8 xds option(s) verified using ActorType enum.
Checking actor Repository... 2 xds option(s) verified using ActorType enum.
Checking actor Document Recipient... 2 xds option(s) verified using ActorType enum.
1 mhd option(s) verified using ActorType enum.
Checking actor Initiating Gateway... 3 xds option(s) verified using ActorType enum.
Checking actor Responding Gateway... 3 xds option(s) verified using ActorType enum.
Checking actor Imaging Document Consumer... 1 xds-i option(s) verified using ActorType enum.
Checking actor Imaging Document Source... 1 xds-i option(s) verified using ActorType enum.
Checking actor Initiating Imaging Gateway... 1 xca-i option(s) verified using ActorType enum.
Checking actor Responding Imaging Gateway... 1 xca-i option(s) verified using ActorType enum.

Process finished with exit code 0

Conformance tests display logic

See ConformanceTestTab#displayTestCollection

TestSorter

Conformance test names are sorted through the front-end client code using a Java class named TestSorter.

History behind some uses of the ActorType#shortName:

Test collection naming conventions change from actor_profile_option to actor(profile)_option. Note: There was a 1:1 relationship between test collection actor and the ActorType. This 1:1 relationship was introduced by BuildCollections#findActorType(collectionName). This was Ok when there was one type of simulator per actor. With the introduction of multiple profiles for the same actor, the 1:1 relationship broke due to possibility of using separate simulators for another profile/option. To fix the problem, we used the tabConfig entirely to map test collections to actor tab in the conformance tool. The actor type has a new actorCode field, which is the test collection code, in case it is needed. If the actorCode is null, the Getter method returns the shortName, else it returns the actorCode.