Types

The GITB specification foresees a type system that is used to better manage ongoing testing state and facilitate calculations. The supported types can be split in three main categories:

• Primitive types: Simple values.
• Object types: XML documents or other complex structures.
• Container types: Structures that can contain primitive and object types or embedded container types.

The following table lists the available types. Note that the value under “Type name” is what needs to be used when referring to a given type in GITB TDL:

Type name	Type category	Description
string	Primitive	Used for text values
number	Primitive	Used for numeric values (integers and floating point numbers)
boolean	Primitive	Boolean values (true/false)
binary	Primitive	A byte buffer used typically to represent file content
object	Object	An XML document recorded as a Document Object Model (DOM)
schema	Object	Identical to an object but with an additional property for a schemaLocation
map	Container	A map of key-value pairs (similar to a java.util.Map).
list	Container	A list of values (similar to a java.util.List)

Map variables

Variables of type map can contain values or any type, with even different types contained in the same map. In fact a map may also contain embedded map variables at any level of depth. The keys of a map are however always strings.

List variables

Variables of type list can contain an arbitrary sequence of elements. A key difference however when comparing to a map is that the elements contained in a list are of a single type. This type is defined when the list is declared in the test case’s Variables section.

Type conversions

It is often the case when executing a test case that we need to convert a session context variable of one type to another. An an example consider a string variable containing XML content that we want to validate using a validator that only expects binary or object input. Conversions between types can be done explicitly using the assign step and the type attribute:

<assign to="$toVariable" source="$fromVariable" type="object"/>

In this example, the fromVariable is converted to the toVariable as an object. Explicit conversions like this can however pollute the testing logic and can in most cases happen implicitly. An implicit conversion takes place when we attempt to use a source variable of a given type as a variable of another type. The supported conversions and specific conversion assumptions between types are provided in the following table:

	string	number	boolean	binary	object	schema	map	list
string	Yes	Yes - parsed as double (e.g. “10” or “5.03”)	Yes - parsed as “true” or “false” (ignoring case)	Yes - result is the string’s bytes	Yes - considered as serialised XML	Yes - same as with object	No	No
number	Yes - result as string (e.g. “10”)	Yes	Yes - result is “true” if 1 otherwise “false”	Yes - bytes of the number’s string representation	No	No	No	No
boolean	Yes - result as string (e.g. “true”)	Yes - result is 1 if “true” otherwise 0	Yes	Yes - bytes of the boolean’s string representation	No	No	No	No
binary	Yes - result is the string representation of the bytes	No	No	Yes	Yes - result is the XML representation of the bytes	Yes - same as with object	No	No
object	Yes - result is the serialised XML	No	No	Yes - result is the XML’s bytes	Yes	Yes	No	No
schema	Yes - result is the serialised XSD	No	No	Yes - result is the XSD’s bytes	Yes	Yes	No	No
map	No	No	No	No	No	No	Yes	No
list	No	No	No	No	No	No	Yes - result is a map of the elements with keys their zero-based list index as string values	Yes

Note

GITB software support: Implicit conversions between types occurs when the expression referencing the source variable is a pure variable reference. For example given a binary variable myVariable, referencing $myVariable when assigning to a string works whereas but concat('My value is ', $myVariable) does not. This is because the second case is a full XPath expression whereas the first case only identifies the variable.