XMLTester provides a framework that allows you to create and manage XRT artifacts. In addition, the XMLTester allows you to execute individual tests, represented by XRT <Case>s, as well as groups of tests represented by XRT <Suite>s and <Plan>s.

When an XRT <Case> is executed, the XMLTester captures the behavior of the target System Under Test using fragments of XML contained within <Observation> tags.

An <Observation> records these things:

• <Location> - path to a message channel or persistent object in your application
• <Time> - the time at which the observation was made
• <Trigger> - any available information about what caused this message
• <Value> - the value travelling over the channel or stored in the object

For example, a SOAP endpoint might be a Location; then the contents of a particular SOAP message received at that endpoint would be recorded as the Value of an Observation at that Location.

These observations are stored in an XMLDB - compliant repository, along with the test cases, test plans, and all other data needed to conduct the testing process. This repository supports XPath queries, which are the key to verification of test results.

Tests are executed, and observations are recorded, through the interaction of XMLTester with what we call "Drivers". A Driver is an outboard program (in any programming language, on any connected platform) that you can customize for your testbed environment. You can start, stop, and restart a Driver without restarting the XMLTester, which is sometimes very useful in a testing environment.

A Driver communicates with XMLTester using a simple XML publish/subscribe protocol which is supported by the open-source XMLBlaster messaging system. XMLBlaster is accessible using CORBA, XML-RPC, RMI, and many other protocols.

Drivers are usually able to send and/or receive messages to/from your target System Under Test. Drivers are responsible for converting these messages to/from a structure compatible with the XMLTester. For example, you might have a Driver that knows how to send input messages TO your target, and another Driver that knows how to record output messages FROM your target system. Or, you might have a single Driver that does both; for example, it might send a SOAP request and wait for the SOAP response.

Once a test has been executed, we can compare the Observations that were recorded with those that are predicted by the <Case>. This is done using "Comparator" plugins that are able to compare actual results with expected results. Comparators (like Drivers) can be implemented in XSLT, java, beanshell, or any other programming language. The output from one or more Comparators can be passed to a Formatter (usually XSLT) to produce a report for the XMLTester client (which can be a browser, applet, etc).