Programming New Test Assertions

The following sections provide an overview of the organization of the Java classes which makeup the test kit. The test kit extends the WS-I implementation and relies on the behaviour of existing base classes wherever possible.

There is an extension point in the WS-I framework which allows us to insert our own factory implementation during initialization. We use these factories to cause our specialized classes to be constructed. The wsi.properties file specifies our factory:

Refer to the diagram below. The classes in yellow are the WS-I base classes and the classes in white are the WSRP extensions. The WSRPValidatorFactoryImpl creates the WSRP specific extensions when the Analyzer is started. The WSRPMessageValidatorImpl class plays an important role in the execution of Test Assertions because there is only one instance of this class for all message Test Assertions. The WSRPMessageValidatorImpl instance is used to share data between Test Assertions or between messages. This is discussed in more detail in a subsequent section.

Refer to the diagram below. Again, the yellow classes are WS-I base classes, and the white classes are WSRP specific. The small class, RP0090, at the bottom of the diagram is an example of a Test Assertion.

Ultimately, all Test Assertions are derived from AssertionProcess. This class declares the validate() method that all Test Assertions must implement. The AssertionProcess class also declares a member variable to hold an instance of BaseValidatorImpl.

WSRPTK introduces 2 intermediate classes between Test Assertions and AssertionProcess. WSRPBaseAssertionProcess is used to implement convenience methods such as pass(), fail(), etc, for setting the result of a Test Assertion, regardless of whether the Test Assertion is on the message artifact side or the description artifact side.

WSRPMessageAssertionProcess extends the WSRPBaseAssertionProcess in order to declare the instance of the specialized WSRPMessageValidatorImpl to which all the Test Assertions need access for data sharing. The BaseValidatorImpl is responsible for parsing and loading the message log file and then creating and invoking the Test Assertions in the Profile. When a Test Assertion Java class, e.g. RP0090, gets initialized, the BaseValidatorImpl passes an instance of BaseMessageValidatorImpl into the constructor. The Test Assertion calls the constructor on it's superclass, WSRPMessageAssertionProcess, passing the BaseMessageValidatorImpl. The superclass forces a cast of the BaseMessageValidatorImpl to WSRPMessageValidatorImpl and saves it in a protected member variable called validator.

This hack is necessary for historical reasons. The original WS-I framework was organized so that all the Test Assertion classes were inner classes of the WSRPMessageValidatorImpl class, and so they had direct access to its methods and state. At some point, the architecture was changed so that the Test Assertions were separated into individual files and this hack became necessary to preserve access to the specialized methods and state of the WSRPMessageValidatorImpl.

As explained above, there is a single instance of this class which is available to all Test Assertions through the use of the protected variable validator. This class offers many convenience methods as well as saving state between messages. Let's look at the following Test Assertion:

This Test Assertion looks at a getMarkupRequest and has to check the value of window state against a set of valid window states which were supplied in the getServiceDescriptionResponse. In the following code fragment, RP0510 uses convenience methods from the WSRPMessageValidatorImpl to locate the offeredPortlet from the saved getServiceDescriptionResponse.

This Test Assertion relies on the fact that another Test Assertion, RP0320 saves the serviceDescriptionResponse. Note that if a log file is analyzed that does not contain the serviceDescriptionResponse message, then any Test Assertion that relies on it will fail.

The WSRPMessageValidatorImpl has many methods which are beyond the scope of this tutorial. The reader is encouraged to examine the source code. The following diagram shows the WSRPMessageValidatorImpl and all the classes it references. Not all the methods are visible.

There are several choices as to which class to extend to create a new Test Assertion. The WSRPBaseAssertionProcess class, the BaseRP class, CustomItemChecker, or an existing Test Assertion. The diagram below shows several Test Assertions and the classes they extend. CustomItemChecker is specialized and is used to parse the markup have a listener called when certain things are found. The BaseRP class checks the message type and then delegates handling of the message to the Test Assertion subclass. This design pattern was introduced after many Test Assertions were already implemented, so you may discover Test Assertions that would have benefited from this approach.

Let's look at a simple Test Assertion.

Here is the source code:

This Test Assertion extends WSRPBaseAssertionProcess and implements the validate() method. It also implements a constructor so it can establish a handle to the WSRPMessageValidatorImpl class. It uses a class called NodeUtils which implements various shortcuts to XPATH for finding nodes in messages.