Java Device Test Suite Developer’s Guide

This chapter describes the optional feature definition file which, if present in your test pack, gives users a way to select tests according to their relevance to features present on a device. To benefit from this chapter, you must understand XML and the XMLSchema language. The chapter covers these topics:

• Package and Feature Concepts
• Package and Feature Implementation

---

Package and Feature Concepts

A test pack’s tests have a package structure and optionally have a feature structure. Java Device Test Suite users can can use these structures to select tests and inspect results in reports.

Package-based Selection and Reporting

FIGURE 22-1 shows part of a configuration’s package tree, which users can use to select tests. This tree is called the package tree, though it also contains classes and test cases. The test tree in the main harness window is also a package-based tree.

FIGURE 22-1 Example Package Tree

The standard test report is also package-based, though the package names are “flattened” into long strings. This report is organized in a hierarchy whose top levels are shown in FIGURE 22-2, FIGURE 22-3, and FIGURE 22-4.

FIGURE 22-2 Standard Report Summary

FIGURE 22-3 Standard Report Passed Tests

FIGURE 22-4 Standard Report Failed Tests

Feature-based Selection and Reporting

The alternative selection mechanism is feature, sub-feature, and test name using the feature tree shown in FIGURE 22-5.

FIGURE 22-5 Example Feature Tree Display

Both the package tree (FIGURE 22-1) and the feature tree (FIGURE 22-5) contain the same tests, but the tests are organized differently. The package tree is more of a developer’s structure. The feature tree is more of a user’s structure.

When a test pack has a feature definition file, test results can be reported by feature as shown in FIGURE 22-6. The feature-based report makes it easy to see what features have problems and which features have not been tested.

FIGURE 22-6 Feature-based Report

For exercises demonstrating both selection and reporting options, see the Java Device Test Suite Tester’s Guide.

---

Package and Feature Implementation

When your test pack is installed, it is added to the package tree. If your test pack has the optional feature definition file, that file’s contents are added to the feature tree and test results appear in feature-based reports.

Package Design

You can design a test pack’s package and class structure for your own convenience. For example, your package structure can model the structure of the specification you are writing tests for. The package structure is expressed in your test pack’s directories and class files.

Feature Design

What constitutes a feature (and its optional sub-features) is your decision. When defining features, adopt a test user’s (administrator’s or tester’s) point of view:

• Help the user assess the consequence of a test failure, that is, what area of device functionality (what feature) is compromised by the failure of a particular test. For example, FIGURE 22-6 shows that the test device has a problem displaying text.
• Help the user decide what tests are pertinent for a given device, that is, which tests to run. Consider the functional clusters that different devices, or models of the same device family, are likely to implement. For example, a portion of a multimedia feature tree might look like this:

Audio Playback MP3

Via File Connection

Via HTTP

Via Input Stream

Via RTSP

Audio Playback WAV

...

Video Capture

...

If a test device does not play WAV files, for example, this structure makes it easy to unselect the WAV tests.

Feature Definition File

You define features and their associated tests in a feature definition file named packWorkDir/metadata/features.xml. The Developer’s Kit sample tests include examples.

CODE EXAMPLE 22-1 shows a hypothetical feature definition file that defines the following hierarchy of features:

Bluetooth

SPP

Receive Attribute

Remove Service

L2CAP

Receive Attribute

Remove Service

In this example, the features happen to correspond closely to the test pack’s package structure, but that is a coincidence. A feature can be composed of any set of tests.

<?xml version="1.0" encoding="UTF-8"?>
<features xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="testpack_features.xsd">
    <feature-hierarchy > 
        <feature name="Bluetooth">
            <description>Bluetooth communication capabilities</description>
            <feature name="SPP">
                <description>Serial port profile (SPP)</description>
                <feature name="Receive Attribute">
                    <description>Receiving attribute on client side</description>
                    <test name="com.sun.jsr082.bluetooth.functional.connection.SPP.receiveInitAttribute" />
                </feature>
                <feature name="Remove Service">
                    <description>Removing service from SDDB</description>
                    <test name="com.sun.jsr082.bluetooth.functional.connection.SPP.removeService" />
                </feature>
            </feature>
            <feature name="L2CAP">
                <description>Logical Link Control and Adaptation Protocol</description>
                <feature name="Receive Attribute">
                    <description>Receiving attribute on client side</description>
                    <test name="com.sun.jsr082.bluetooth.functional.connection.L2CAP.receiveInitAttribute" />
                </feature>
                <feature name="Remove Service">
                    <description>Removing service from SDDB</description>
                    <test name="com.sun.jsr082.bluetooth.functional.connection.L2CAP.removeService" />
                </feature>
            </feature>
        </feature>
    </feature-hierarchy>
</features>

A feature definition file must conform to the XML schema defined by devKitHome/tests/common/lib/testpack_features.xsd. You can use this schema file to validate your feature definition file in an XML editor. When you build a test pack, the build script validates your feature definition file against the schema and verifies that every test mentioned in a feature definition exists and that every test is mapped to one feature.