Defining a New Test Configuration

Currently, TEE supports the OSGi Framework Configuration Model and the Reference Test Case Configuration Model.

Prerequisites: Depending on the place of the test configuration, there are internal and external test configurations. The internal test configurations are packed in the test case JAR file. The Runtime Assertion Model supports internal test configurations obeying the rules of the OSGi Framework Configuration Model. The external test configurations are placed in the ../../../tee/sa/configs directory and should follow the config_<test_case_name>_.xml naming convention. They can be loaded with the "-c" option of the execute TEE console command.

You can use the available system properties to manage the provided test configurations.

Using Internal Bundles

The following table contains a description of the elements of a test configuration defined by the OSGi Framework Configuration Model:

Element	Description

osgi-config (property, feature, bundle*)	The root element of the external configuration. Optionally, it can have one or more property, feature and bundle elements. The attribute of this element must be String. The default value of this element's attribute is "OSGi Framework Configuration".
property (prop-value)	Optional. The system property that will be used through the test case execution. The maximum number of system properties that can be defined is 100. The default element's attribute is "key".
prop-value	Required. The value of the system property specified with the property element. This element is with cardinality 1.
feature(feature-value)	Optional. Holds a requirement to the target platform or bundle that should be met prior to test case execution. Following are the values of the target platform features that can be used: Basic features – arch, os.name, os.version, jvm.name, jvm.version, target.name, target.version, security.algorithm. The value of security.algorithm has the format EngineClass:Algorithm and supports negation, for example: !java.security.Signature:MD5WITHRSA OSGi-specific features or features specific to the OSGi framework – configadmin, faultman, certman, flashman, security, fileaccess.type, loader.type, native.time, lazy.servs, service.reg, sys.prop, required.class, transactionman and release.
feature-value	Required. Contains the value of the target platform requirement.
bundle(action, feature, property, action-delay?, object-class+)	Optional. Holds the configuration of a specific bundle. The maximum number of bundles that can be configured before test case execution is 400. It can have the following elements: action, feature, property, action-delay and object-class. Refer to the Examples below with the property as sub element.
action	Required. Defines what action to be executed on the specific bundle before running the test case. There are four possible actions - install, install & start, start, stop and uninstall. Its default value is install & start.
action-delay	Optional. Specifies an optional pause (in milliseconds) after an operation is performed on a bundle. The default value is 1000 milliseconds (ms). The minimum value of this element is 1ms.
object-class (attribute+)	Optional. Contains the information about an ObjectClassDefinition as defined in the OSGi Service Platform Service Compendium Specification, Release 4. This element must have at least one attribute element. The maximum number of Object Class Definitions that can be defined for a bundle is 100.
attribute (cardinality, (string\| boolean\| char\| byte\| short\| int\| long\| float\| double))	Required. Holds the metadata for an AttributeDefinition as defined in the OSGi Service Platform Service Compendium Specification, Release 4. It should have one cardinality element and one of the elements specifying the type of the attribute – string, boolean, char, byte, short, int, long, float and double. The maximum number of Attribute Definitions that can be added is 100.
cardinality	Required. Defines the maximum size of an array or a vector. Positive value indicates that the attribute's value is an array, negative – that this is a vector. The default value is 0 which indicates that this is a single value attribute.
Elements showing the possible types for an attribute
string	Specifies the type of a string attribute.
boolean	Specifies the type of a boolean attribute.
char	Specifies the type of a char attribute.
byte	Specifies the type of a byte attribute.
short	Specifies the type of a short attribute.
int	Specifies the type of an integer attribute.
long	Specifies the type of a long attribute.
float	Specifies the type of a float attribute.
double	Specifies the type of a double attribute.

Examples

The config.xml located in the bosch-iot-gateway-sdk/runtime/osgi/demo/com.prosyst.mbs.tee.junit-demo/src/main/resources directory is an example of an external test configuration that follows the OSGi Framework Configuration Model. With this demo configuration file you can do the following:
- set a system property tee.test.prop with value test42:
    <property tree:value="tee.test.prop">

        <prop-value>test42</prop-value>

    </property>
- install an OSGi log bundle depending on the target platform.
    <bundle tree:value="log.jar">

        <action>install</action>

        <action-delay>1000</action-delay>

        <feature tree:value="fileaccess.type">

            <feature-value>javaio</feature-value>

        </feature>

    ...

    </bundle>

The way you could have a feature as a root and in a bundle, you can have also property. Here is how you can use the property element as a sub-element of the bundle:

    <bundle tree:value="your.bundle.name.jar">

        <action>install&start</action>

        <property tree:value="property.nameType">

            <prop-value>xml</prop-value>

        </property>

    </bundle>

A test case can contain internal bundle. They have to be described in the config file in the standard way, except the location of the bundle must be declared as tcjar://<entry-name>:

    <bundle tree:value="tcjar://res/tb1.jar">

        <action>install</action>

    </bundle>