Introduction to XML Schema in TestDriver Schema

TestDriver V2 is driven by a single input XML Schema that defines the tasks to be performed. This XML schema is also called as driver file and is detailed in the following section.

Tests are organised as <tasks> where, each tasks is a set of operations to be carried out on the PC or on the Symbian device. In addition to tests, an operation may consist PC command line tasks, Symbian command line tasks, transferring between the two systems that are discussed in the following sections.

Conventions used in the following sections are explained below:

Each box represents an XML element also called as a tag (see figure 1), where top rectangle is the name of the tag, <task> in this case, and middle rectangle contains the attributes (represented by circled 'a') that the main tag can have, name and timeout in this case. The bottom most rectangle contains the the elements/tags that the main tag can contain, for example, <executeOnPC>, <transferToSymbian> etc.

Task that can be run within a main task is called a subtask.

Figure 1. An element/tag

The generic XML structure defining tasks that are used to run tests is shown below:

Figure 2. TestDriver Schema.

The <driver> is the root node of the TestDriver files. This must contain a <task> element and can contain one <driverInfo> element:

The structure of a typical driver file would be the following:

Driver xml file

The <task> tag is a logically grouped set of operations to be executed by the TestDriver. The container task for all other tasks. It is represented by the name, a unique name identifing the task. A task has timeout in seconds. When the timeout is less than or equal to 0 seconds, it is considered as no timeout.

Note: When executing the asynchronous tasks, set the value of timeout to greater than 0.

Any operation including a non-test related operation, can be run using the following tasks, placed within the <task> element. A task can be one of the following:

task: A container of other tasks:
executeOnPC: A task executing something on the PC device.
executeOnSymbian: A task executing something on a Symbian device.
transferToSymbian: A task transferring to a Symbian device.
retrieveFromSymbian: A task transferring from a Symbian device

The diagram shows the operations that can be performed under a task.

Figure 3. Operations in a task

To simplify the process of running the common tasks, such as Test Execute Framework (TEF) test or build the Symbian code, subtasks are made available to these tasks which combine any of the four tasks into a single tag. The details of the subtags and its attributes are discussed in the respective sections.

Operations are categorised based on the phase of the TestDriver in which these operations are executed:

TestDriver uses two main commands 'testdriver build' and 'testdriver run' to buld and run tests respectively. These commands walks through the XML tree ( link would be provided) starting from the element specified by the -s switch . For more details, see Building tests.

Running the 'testdriver build' command (see command reference for more details) involves the following operations:
1. executing all operations within <executeOnPC>
2. creating the repositories/SIS files for the <transferToSymbian> operation.
Running the 'testdriver run' command (see command reference for more details) involves the following operations:
1. executing all operations in <executeOnSymbian>
2. transfering the created repositories/SIS files in the build phase to the Symbian device (hardware or emulator) for the <transferToSymbian> operation and any other operations
3. retrieving files from the Symbian device in the <retrieveFromSymbain> operation.

Note: All operations in a task are executed in the order they appear in the XML file.

Tasks can be run in two modes:

synchronous mode, where the TestDriver launches tasks and wait for them to terminate or till time out
asynchronous mode, where the TestDriver launches tasks without waiting for them to terminate.

When all operations in a task are completed, the TestDriver waits for subtasks to finish or kill them if they have timed out before doing the clean-up.

Each driver file contains <driverInfo> tag that has additional user information which would be printed in the report, for example, description, testcase. This is not directly used by the TestDriver. It works as an annotation tool for .driver files.

Figure 4. Driver information

Example for <driverInfo>

An example for an xml file to describe a <driverInfo> task is:

<reportInfo> <info key="use case">Testing TestDriver</info> <info key="discription">This is an annotation for TestDriver files</info> <info key="random key">some value</info> </reportInfo>

This subtask allows you to refer to another task in the current or another xml file. This acts like an import statement. Here you need to specify fully qualified URI using the attribute URI. The URI accepts the following variables: ${epocroot}, ${sourceroot}, ${xmlroot}, ${platform} and ${build} and does not allow wildcards. Currently the TestDriver supports file protocol.

Figure 5. Refering to another task

Example for <reference>

An example for an xml file to describe a <driverInfo> task is:

<reference URI="file:/h:/epoc32/testdriver/plattest/plattest.driver#plattest.pt_coretests" />

This task refers to the file plattest.pt_coretests that is in the location h:/epoc32/testdriver/plattest/plattest.driver.

This task allows you to transfer a file from the PC to the Symbian device. When used within transferToSymbian task, wildcards and variables are allowed. When used within retrieveFromSymbian task, wildcards and variables are not allowed.