Test Assertion Plugins

Test Assertion Plugins

What is an assertion plugin

An assertion plugin is an external Groovy source code file containing a single class that extends the AbstractSoapValidator. The class defines instance parameters and overrides the abstract validate method. The validate method takes a SoapSimulatorTransaction object and returns a ValidaterResult object.

Where are the assertion plugins loaded from?

Assertion plugins are loaded from the plugins directory of the testkit search path. It uses the same search path as the testkit.

Types of assertion plugins

Although more than one type of assertion plugins is defined through the PluginType Java enumeration, only the SOAP_ASSERTION or ("SOAP") assertion type is actively used in the XDS Toolkit.

Purpose

An assertion plugin is used to validate client transactions using the Assertions element of a NullTransaction TestPlan XML element. A NullTransaction simply allows to validate an arbitrary transaction pulled from the simulator transaction log events.

Example Test

xdstools2\src\main\webapp\toolkitx\testkit\tests\XdsIsrSubmissionTest-1113

<TestPlan>
    <Test>XdsIsrSubmissionTest-1113/AssociateExistingDEwithExistingFolder</Test>
    <TestStep id="validate">
        <ExpectedStatus>Success</ExpectedStatus>
        <NullTransaction>
            <Assertions>
                <Assert id="assert">
                    <SimReference id="isr_support" actorType="reg" transaction="rb"/> <!-- This sim is created by the conformance actor's orchestration -->
                    <Validations type="SOAP">
			            <ExpectedContentsValidater filterDescription="Check Response Status" responseMsgExpectedContent="RegistryResponseIsValid" />
                        <ExpectedContentsValidater filterDescription="SubmissionSets count should be 1" requestMsgExpectedContent="SubmissionSets" requestMsgECCount="1"  />
                        <ExpectedContentsValidater filterDescription="Document Entry count should be 0" requestMsgExpectedContent="Documents" requestMsgECCount="0"  />
                        <ExpectedContentsValidater filterDescription="Associations count should be 2" requestMsgExpectedContent="Associations" requestMsgECCount="2"  /> <!-- 1. ss-HasMember-de 2. ss-hm-assoc -->
                        <!-- FolderSourceAssociationValidater cannot be extracted to a Step/GetFolders Transaction because when the Step executes, the SUT is not in Responder mode. Since we are only checking logs, we need to code a plugin to query our supporting sim. -->
                        <FolderAssociationValidater filterDescription="Checks Folder Association through StoredQuery" totalAssociationsInSs="2" docEntryScopeCheck="Registry" />
                        <!-- find an association
                        1. where associationType='HasMember'
                        2. sourceObject != SSid. When True, record this Id has as a parameter to be used in GetFolder SQ
                        3. target = DocId
                        -->
                    </Validations>
                </Assert>
            </Assertions>
        </NullTransaction>
    </TestStep>
</TestPlan>

The SimReference element in the example above, <SimReference id="isr_support" actorType="reg" transaction="rb"/> is a reference to an XDS Toolkit simulator that acts as the responder to the client test. The id attribute is the simulator name without the test session prefix. The actorType is the simulator actor type. The transaction is the type of transactions to filter from the simulator event database, in this case rb denotes a XDS.b Register type transaction. The attributes are used to locate the simulator and only pulls the 50 most recent transactions at the time user of clicking the Validate button. A transaction object contains the SOAP request body, SOAP response body, and HTTP headers. Each transaction is feed into the validator.

In the example above, ExpectedContentsValidater is the assertion plugin created from the plugins\SoapAssertion\ExpectedContentsValidater.groovy source code file. The XML element attributes such as the filterDescription and responseMsgExpectedContent are mapped to the class instance variables when a new instance of the class is made. The ExpectedContentsValidater is a special class in that it makes any regular TestPlan ExpectedContents assertion such as the

  <ExpectedContents>
    <SubmissionSets count="0"/>
    <Associations count="0"/>
    <Documents count="0"/>
    <Folders count="2"/>
  </ExpectedContents>

available to be used through the assertion plugin.

Assertion plugins for integration tests during a Maven build

For the Maven integration-test build phase, be aware that there is another test-copy of the ExpectedContentsValidater assertion plugin in the it-tests Maven module Java source code folder. This plugin must be kept in sync with the main source code.

Client Validation References: Integration Test Plugin directory (Plugin test area) iheos-toolkit2\it-tests\src\test\resources\war\toolkitx\testkit\plugins

SOAP Assertion Validators: iheos-toolkit2\it-tests\src\test\resources\war\toolkitx\testkit\plugins\SoapAssertion