Adding an Option Tab to the Conformance Test Tool

Adding a new Actor Option in the Conformance Test Tab

Actor Options are configured in a actor's orchestration builder class. For example, a Responding Gateway (RG) actor has its options configured in the BuildRGTestOrchestrationButton class as shown below. (Naming of the ACTOR_OPTIONS should be consistent through out all actor-option configurations.)

public static List<ActorAndOption> ACTOR_OPTIONS = new ArrayList<>();
static {
    ACTOR_OPTIONS = java.util.Arrays.asList(
            new ActorAndOption("rg", "", "Required", false),
            new ActorAndOption("rg", XUA_OPTION, "XUA Option", false));
}

If no other Options besides the Required Tests Tab is desired, the ACTOR_OPTIONS list can be omitted.

In the event an ACTOR_OPTIONS list is defined for the first time in an orchestration builder class, it must be registered in the ActorOptionManager class by adding it to the actorOptions map as a key/value pair as pointed out below:

static {
    actorOptions = new HashMap<>();
    actorOptions.put("ig", BuildIGTestOrchestrationButton.ACTOR_OPTIONS);
    actorOptions.put("rg", BuildRGTestOrchestrationButton.ACTOR_OPTIONS); <-- 
    actorOptions.put("reg", BuildRegTestOrchestrationButton.ACTOR_OPTIONS);
    actorOptions.put("rec", BuildRecTestOrchestrationButton.ACTOR_OPTIONS);
};

Orchestration

The orchestrate method in the actor orchestration builder class defines how the supporting environment of a System Under Test (SUT) is brought to existence.

SAML

For some SUTs such as the Registry actor, SAML is used in the orchestration through the SAML checkbox in the Conformance Test Tab Actor page. Some combined-features SUTs such as the Responding Gateway, orchestration is performed without SAML due to a system limitation with propagating SAML from one host to another host.

The SAML checkbox is also used when running tests through the Conformance Test Tool tab. For all other Options except the XUA Option, Xuagood SAML assertion is retrieved from an Secure Token Service (STS) site. Please note, at the moment, Toolkit is configured to use Gazelle STS as the default service provider (more on this later). SAML assertions are applied to tests that are run as a collection or an independent test or a test section by itself.

When the entire test collection is executed, through the Play button icon on the Test Overview header, a SAML assertion is retrieved once and applied to all the tests in the test collection. This means a single SAML assertion is reused for the entire test collection.

When a single test is run, through the Play button at the test level, a new SAML assertion is retrieved just for that test.

(For information on SAML using other tools such as FindDocuments and Simulator configuration, see SAML Validation using Gazelle.)

SAML for the XUA Option

Tests that use other types of Gazelle STS usernames such as Xuabad, see this page Gazelle STS Xua usernames, are grouped by the xua test collection. For example, XUA Option Tests for the RG actor are tagged by the rg_xua text value in the collections.txt file in the Toolkit's test kit test plan folder.

XUA Option Tests follow a special naming convention that is easier to maintain than embedding instructions within the test plan. The username is coded as the last part of the test instance name separated by an underscore character. For example 15808_Xuabad implies Xuabad SAML assertion is used for all step transactions, in the all sections, within a test plan. This convention only applies to the XUA Option and has no effect on other actor options.