TEAM Engine & CTL Quick Start

Note: This instructions apply for TEAM Engine 3.0. TEAM Engine 4.0 Beta have been mavenized and building of the code is different. More details at Sourceforge.

The Test, Evaluation, And Measurement (TEAM) Engine is a test script interpreter. It executes test scripts written in Compliance Test Language (CTL).

Installation

Make sure you have JAVA

TEAM Engine is a Java application. It depends on Java 1.5 or greater. To check the version of Java installed on your system open a command prompt window, and try the java command:

C:\>java -version

This should display the version of Java that is in your path. If the version number is 1.5 or greater, you are good to go. If you get an error message or a number less than 1.5, you may need to install a standard Java Runtime Environment (JRE). You can find it on Oracle's Java page.

Download TEAM Engine from SourceForge

Download the TEAM Engine binary distribution archive from SourceForge, and extract the files. The root directory of your hard drive would be a good location to extract them to. You can also get the latest code from SVN as explained here.

Test TEAM Engine

Go to where the extracted files are and navigate to the bin folder:

...test-release/teamengine2.0/bin

Make sure you can execute the files under these bin folder (*.sh and *.bat). .sh is used for *nix environment, and .bat is used for the Win32 environment. You may need to change the permissions so you will be able to execute these files. For example, when you are under the bin directory, in unix you can type

Explanation of how TEAM Engine works

TEAM Engine executes tests written in CTL, a test scripting language which specification can be found at the OGC Portal. When a test suite is executed, the source CTL files are converted into XSL files, a separate XSL file for each test. TEAM Engine presents a web form for a user to select a test suite to the user. The values the user enters are parameters to the starting test, and they are converted into parameter XML. Then the starting test is executed by starting a Saxon transformation using the parameter XML as input and the XSL file that was generated for the starting test as the stylesheet.

The XSL code makes calls to java extension functions. These include a method for calling a subtest, which works by performing another Saxon transformation using the XSL that was generated for the subtest. The transformations write output to the console and generate log files as they progress.

This is one of the simplest test scripts that can be written. It contains a single test. Tests are identified by a namespace qualified name attribute. In this case, we have made up our own namespace "urn://mynamespace" identified by the prefix "my" which we are using in the test name. A test has an assertion, which is a statement that is true if what is being tested is compliant. It also has code that determines whether the assertion is true or false. This test isn't really testing anything. The code merely displays a greeting on the console, and the assertion just describes what the code does.

TEAM Engine starts by processing the source file, converting the CTL source code into XSL code that it will execute. The XSL files it produces are stored in a work directory. We could have told TEAM Engine what directory to use for these files using the -workdir option. Since we didn't, it created its own work directory. This directory and the files in it are not removed. TEAM Engine will reuse the files instead of recreating them if we execute the same source file again, unless the source file has been modified.

TEAM Engine displays the test name and the assertion, and then executes the test code. In this case, the code just displays the message "Hello, world!" Then TEAM Engine tells us whether the test passed or failed. In this case, the test will always pass since we did not provide for any failure conditions in the code.

Suppose we want to test this note. We want to make sure that it has a heading that contains more than just whitespace characters. We also want to make sure that it has from and to fields that identify known users. Here is a test script.

There is still just one starting test called note:main, but it calls several subtests. Because there are several tests in the same file, they are grouped inside a package element.

The request instruction retrieves the note XML. The note contents are assigned to the variable named response, that encloses the request instruction.

If the root node in the response variable is a note element as it should be, then we will call the subtests that check various aspects of the note. Otherwise, we display an error message and use the fail instruction so that this test fails.

Our check-heading test receives the heading as a parameter. It uses the XPath normalize-space function to condense whitespace in the header's text content. If the header contains nothing but whitespace so that it normalizes down to an empty string, we use the fail instruction so the test fails.

The check-user test is used for both the from and the to elements in our note. It receives the user as a parameter. The assertion text contains a parameter name substitution code for the user parameter. When the test is executed and the assertion text is displayed, the value of the label attribute supplied with the user parameter replaces "{$user}". The code checks to see if the user is Tove, Jim, or Jan. If not, it falls through to the fail instruction so the test fails.

The second call to check-user fails, since in our test "Jani" is not one of the names we recognize. Because this test fails, the parent test (main) also fails. When a test fails because a child test fails, it is an inherited failure.

Specifying Parameters on the Command Line

Suppose we want to check our own note rather than always checking the note on the w3schools site. We can create our own note, with a valid "from" user. Then with a slight modification to our code, we can check it by passing the URL for our note to our test as a parameter.

Supply a Starting Form

Specifying parameters on the command line may be fine for developers, but it is somewhat tricky for end users. To help them along, we can create a formal test suite element that includes a starting form.

The suite element formalizes our set of tests by giving them a title and description. It identifies the starting test to execute, and provides a form that is used to prompt the user for the values of the parameters of the test. The form contains XHTML elements, including <xhtml:input type="text"/> (text box) elements. There is an input element with a matching name attribute for each parameter in starting-test. The form also has a <xhtml:input type="submit"/> (Submit button) element so the user can submit the form.

We could have put the suite element inside the package element in the same file that contains our tests, but we need to know how to work with multiple source files anyway. We can start the test suite by supplying two -source parameters.

C:\teamengine2.0>bin\test -source=suite.ctl -source=note2.ctl

Alternatively, we could put suite.ctl and note2.ctl into their own directory (we'll call it notedir), and set the -source parameter to the directory name.

C:\teamengine2.0>bin\test -source=notedir

With the second form, TEAM Engine reads all .ctl and .xml files in notedir as source files.

In either case, TEAM Engine should find our suite element, display the form, and call the starting test using the input we enter as parameter values. This works because there is only one suite element in our source files. If there were more than one suite, then we would also have to supply a -suite option to identify the one that we want to execute.