Introduction to XML Schema

TestDriver V2 is driven by an input XML structure defining tasks to be performed. TestDriver V2 uses a new XML format built on an XML schema (also called as driver file) which is detailed in this 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.

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

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

• <task>

• <driverInfo>

The <task> tag is a logically grouped set of operations to be executed by the TestDriver. 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 four tasks, placed within the <task> element.

1. executeOnPC

2. executeOnSymbian

3. transferToSymbian

4. retrieveFromSymbian

The diagram shows the operations that can be performed under 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. This is not directly used by the TestDriver. It works as an annotation tool for .driver files.

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>

The example provides the information about the TestDriver.

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.

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.

TestDriverV1 XML format

Execute on PC

Execute on Symbian

Transfer to Symbian

Retrieve from Symbian

Using TestDriver with Platform Security