Combining TestCase templates with data sources

Once a TestCase is changed into a template, you can link the TestSteps from the automated TestCase to the test data in the template. The TestStepValues are thus linked with the attribute values of the data source.

A path is entered into the TestStepValue which refers to the data in the data source.

The ActionModes defined in the TestCase template are inherited by the relevant instances when TestCases are created dynamically.

Specifying paths for test data

In Tosca Commander, TestSteps are combined with test data by using attribute names. Structured attributes in the TestCases view can be linked by specifying the attributes of the corresponding levels. The attributes are specified separated by dots.

References to classes can also be created without any attributes. In this, the included instances are transferred as values for the TestStepValues.

The syntax for this combination is as follows:

Syntax:

{XL[<Level 1>.<Level 2>.<Level 3>.<Level 4>]}

Structure levels in templates

The first name of the customer should be written to the TestCase template. The test data is structured in TestCase-Design. In order to create a link to the attribute First name, the structural level Person is added to the syntax. Both structure levels are separated by a dot.

The syntax for the references is: {XL[Person.First Name]}.

Reference to TestCase-Design

For detailed information on how to link test data from TestCase-Design, please refer to chapter "Link a TestSheet to a TestCase Template".

Specifying paths to test data in the name

If TestSteps are linked to test data in the TestCase Template, you can either specify attribute names in the according TestStepValues (see chapter "Specifying paths for test data") or in the name of the TestStep, TestStepValue or TestStepSubValue.

To be able to modify the name of the TestStep, TestStepValue or TestStepSubValue, you have to add the parameter ExplicitName to the Module.

In this example, the first names from a table are specified as XL links in the TestCase Template. The path to the test data is entered into the Name column of the TestCase Template Table.

The syntax for the link is as follows: {XL[FirstName]}.

If the TestCase Template is instantiated, the first names from the table are shown in the TemplateInstance (see chapter "Creating TemplateInstances").

Link in the Name column

Specifying relative paths for test data

Relative paths enable to link TestSteps with test data from the template more easily. The static part of the path is indicated in the Path column, and the relative part of the path in the corresponding TestStepValues.

The syntax for relative paths in TestStepValues is as follows:

Syntax:

{XL[.Attribute]}

The leading dot ensures that one or more parts of the absolute path get abstracted.

The Path column must be added via the Add or remove columns.

The syntax for absolute paths in the Path column is as follows:

Syntax:

Level_1.Level_2.Level_n

Relative paths

Preparing the conditional instantiation

In order to make multiple instantiation of TestCases more flexible, the following objects can be linked with business-based conditions:

  • TestCase Template

  • Any TestSteps and XTestSteps within TestCase templates

  • TestStep folders within TestCase templates

  • TemplateInstances

  • XTestStepValues

During instantiation, these TestSteps are only included in the TestCases if they fulfill the defined conditions.

With the conditional instantiation, the inclusion of dialog sequences in a TestCase depends on whether the data source contains the corresponding value for the specific business object or attribute in the template.

Thus minimal differences in the dialog steering can be mapped in a template as well.

The property Condition defines the conditional instantiation. This property can be set in the Properties view or in the Details view. In the details view, the corresponding column can be added via the Column Chooser (see chapter "Add or remove columns") if needed.

Please note that the Conditions column is used in TestCase Templates only if you want to apply conditions during instantiation. If you want to create conditional statements within your TestCase, please see chapter "Using conditional statements and loops in TestCases".

Objects that are labeled as conditionally instanced change their symbol, for instance TestCase folders:

Defining conditions

The syntax for conditions is as follows:

Syntax:

<Level_1>.<Level_2>.<Level_n><Operator>"<Value>"

Conditional instantiation

Syntax definition

Syntax definition of conditions

<Level_n>

The name of an attribute. Attribute names must start with a character.

The following properties can be specified as attributes: Name, Character, Position and Comment. The respective property must have the attribute Instance as a prefix.

Example: Instance.Character!="Invalid"

<Operator>

You can use the following operators:

<Value>

The value that has to be set to fulfill the conditions.

If the attribute value is either a string, or a date or time format, this must be put between quotation marks.

Example

Insurant.Person.Sex=="male"

The following functions are additionally available:

Conversion functions

ASFLOAT (<level_n>)

This function is used to convert either a STRING (if it contains a FLOAT value) or an INT value into a FLOAT value.

ASINT (<level_n>)

This function is used to convert a STRING (if it contains an INT value) into an INT value.

ASSTRING (<level_n>)

This function is used to convert any values into a STRING.

Example

ASFLOAT(A) = ASFLOAT(B)

NULL can be used as a value:

The analysis of the condition Path==NULL is TRUE if the Path value is either {NULL} (explicit null) or an implicit null (gray background).

Special characters in conditions

All characters except for A-Z, a-z and 0-9 must be escaped with a backslash. This rule does not apply to operators.

As shown in the examples below, special characters in the condition itself require escapes. However, the value of the condition is a string (e.g. "X"), and does not require additional escapes.

Product.vehicle\-insurance=="X"

Complex conditions using many special characters can be limited by an apostrophe [’]. The entire string is transferred along with all special characters.

’Product.vehicle-insurance’=="X"

If the operator contains a greater than or less than sign (<, >, <=, >=) and a numeric value (all natural numbers), the attribute value must be specified without any quotation marks.

ASINT(Age)<17

Linking conditions

To be able to work more effectively with the conditional instance, it is possible to incorporate several (even different) attributes in a condition and to link individual components via operators.

Linking conditions

Description

Syntax

AND Boolean operation

<term1> && <term2>

OR Boolean operation

<term1> || <term2>

The individual terms are resolved according to Boolean algebra (bracket composition is not supported).

To validate only male persons above the age of 18, the condition must be as follows:

person.gender=="male" && person.age>=18

Assigning conditions by using drag and drop

Conditions can either be defined manually, or they can be assigned via drag and drop. This drag & drop operation can be performed with any objects which may contain conditions.

The TestCase template must be linked with the TestSheet or the class that contains the object. Attributes and instances can be assigned as conditions. The drop operation must be performed in the Condition column of the respective object.

Conditions that have been created from an instance always use the operator == (equals). This can be replaced manually if necessary:

  1. Select the object which is relevant for the condition.

  2. Hold the left mouse button down and drag this object to your preferred position in the TestCases section.

  3. Release the left mouse button. The Value field of the target object shows the path to the selected TestCase-Design object.

Assigning conditions via drag & drop

The following standard conditions are defined for specific TestCase-Design objects upon a drag and drop operation:

  • If an attribute is dragged into the TestCases section, the following information is by default entered under Condition:

    <Attribute name> != NULL

    All TestSteps, which are not empty, are included in the instantiation process.

  • If a {NULL} instance is dragged into the TestCases section, the following information is by default entered under Condition:

    <Attribute name> == NULL

    Only TestSteps, which are empty, are considered for instantiation.

  • If an {EMPTY} instance is dragged into the TestCases section, the following information is by default entered under Condition:

    <Attribute name> == ""

    All TestSteps, which have the value {EMPTY}, are considered for instantiation.

Reusable TestStepBlocks in the TestCase template

If a valid link exists in a TestCase template between a TestStepBlock reference and a data source, it is converted into a concrete TestCase during instantiation. If no such link exists, the reference in the template instance is maintained. For further details on Reusable TestStepBlocks, please see chapter "Use TestStepLibraries".