Using the Conditions Elements

You can define Conditions elements in the Control\Identification\Browser element defined for a test object class. This enables UFT One to identify the controls that should be represented by this test object class, based on the control's properties, without calling an identification function.

Alternatively, you can define an identification function (per test object class or for the whole toolkit) and use the conditions to limit the times UFT One calls the function. You do this by defining that the identification function be called only in cases when the control's properties meet certain conditions.

You can define different sets of conditions for UFT One to use when running on different browsers, or you can define one set of conditions and specify that it is relevant for all browsers. For more information, see the Browser element description in the Toolkit Configuration Schema Help.

You compose the Conditions using a set of Condition elements, joined by either and or or logic. Each Condition element specifies a certain property of the HTML control, and the expected value for that property. The condition is met if the value in the control's property matches the specified value (you can specify in the condition whether the value must be equal or not equal to the specified value). You can nest Conditions elements to create complex logic.

For each set of conditions, that is for each top-level Conditions element, you specify one of the following types, instructing UFT One how to treat the control if its properties match the conditions within it:

  • IdentifyIfPropMatch. If the conditions in this element are met, use the current test object class to represent the control.

  • CallIDFuncIfPropMatch. If the conditions in this element are met, call the identification function to check this control. Otherwise, do not use the current test object class to represent the control.

  • SkipIfPropMatch. If the conditions in this element are met, do not use the current test object class to represent the control.

If an identification function is defined, and checking the conditions does not enable UFT One to determine whether to use the current test object class to represent the control, it calls the identification function.

  • If a Conditions element of type IdentifyIfPropMatch is defined, it is checked before the other types.

  • If both CallIDFuncIfPropMatch and IdentifyIfPropMatch Conditions elements are defined, the Conditions of type CallIDFuncIfPropMatch are checked only if the Conditions of type IdentifyIfPropMatch are not met.

  • If both SkipIfPropMatch and IdentifyIfPropMatch Conditions elements are defined, the Condition of type SkipIfPropMatch are checked only if the Conditions of type IdentifyIfPropMatch are not met.

  • A Conditions element of type SkipIfPropMatch is not checked if a Conditions element of type CallIDFuncIfPropMatch is defined.

  • If you nest Conditions elements, the type attribute of the nested elements is ignored.

For each custom control that it handles, UFT One performs the following procedure to determine which test object class to use for the custom control:

  1. If an identification function is defined at the toolkit level (in the CommonIdentification element of the toolkit configuration file), first check the Identification\Conditions elements in all of the Control elements, to determine whether calling the function can be avoided.

    For each Control element:

    1. If an IdentifyIfPropMatch condition is defined and the custom control's properties meet the condition's requirements, use this Control element's test object class. Otherwise, continue with the following steps.

    2. If a CallIDFuncIfPropMatch condition is defined and the custom control's properties do not meet the condition's requirements, do not use this Control element's test object class.

      3. If this Control element does not contain a CallIDFuncIfPropMatch condition, continue with the following step.

    3. If a SkipIfPropMatch condition is defined and the custom control's properties meet the condition's requirements, do not use this Control element's test object class.

    After checking all of the conditions, call the toolkit level identification function unless a matching Control element was found or the conditions in all of the Control elements indicate not to use this Control element's test object class.

    The identification function returns the name of the test object class to use to represent this custom control.

  2. If no identification function is defined at the toolkit level, check the Control elements one by one. Each Control element is defined for one test object class.

    For each Control element, perform the following steps to determine whether to use this element's test object class for the custom control. Use the first matching Control element:

    1. If an IdentifyIfPropMatch condition is defined and the custom control's properties meet the condition's requirements, use this Control element's test object class. Otherwise, continue with the following steps.

    2. If a CallIDFuncIfPropMatch condition is defined and the custom control's properties meet the condition's requirements, continue with step d. If the custom control's properties do not meet the condition's requirement, do not use this Control element's test object class.

      If this Control element does not contain a CallIDFuncIfPropMatch condition, continue with the following steps.

    3. If a SkipIfPropMatch condition is defined and the custom control's properties meet the condition's requirements, do not use this Control element's test object class. Otherwise, continue with the following step.

    4. If an identification function is defined within this Control element, run it to determine whether to use this element's test object class for the custom control. The function returns true or false. If this Control element does not contain an identification function, do not use this Control element's test object class.

When comparing the value of an HTML property specified in a condition with the specified expected value, the following rules apply:

  • String value comparisons are not case-sensitive.

  • You can instruct UFT One to treat the string provided in the expected value as a regular expression. In this case, set the is_reg_exp attribute to true.

  • Numeric value comparisons simply compare the numeric values.

  • When comparing a Boolean value, the values true, 1, and yes are all considered true. The values false, 0, and no, are all considered false.

  • If the HTML property that you are checking returns an object, use valid and null as the expected values. The property is considered valid if it successfully returns an object, and null if it fails to return an object.

  • Set the equal attribute in the Condition element to false if you want to check if the property does not have a certain value.

  • Set the trim attribute in the Condition element to true if you want UFT One to remove leading and trailing spaces from the property value and the expected value before evaluating the condition.

The examples below illustrate different ways that you can use the Conditions element.

If the custom control has a CalendarBehavior or PopupBehavior property defined, UFT One calls the isCalendar JavaScript function to determine whether to use a TSGCalendar test object to represent the control. Otherwise, it continues to the next Control element in the toolkit configuration file and checks whether it matches the custom control.

<Control TestObjectClass="TSGCalendar">
    <Identification type="javascript" function="isCalendar">
      <Browser name="*">
        <Conditions type="CallIDFuncIfPropMatch" logic="or">
            <Condition prop_name="CalendarBehavior" expected_value="valid"/>
            <Condition prop_name="PopupBehavior" expected_value="valid"/>
        </Conditions>
      </Browser>
    </Identification> 
</Control>

If the custom control has an AccordionBehavior property defined, UFT One uses a TSGAccordion test object to represent the control. Otherwise, it continues to the next Control element in the toolkit configuration file and checks whether it matches the custom control.

<Control TestObjectClass="TSGAccordion">
    <Identification>
      <Browser name="*">
        <Conditions type="IdentifyIfPropMatch" logic="and">
            <Condition prop_name="AccordionBehavior" expected_value="valid"/>
        </Conditions>
      </Browser>
    </Identification> 
</Control>

If the value of the custom control's className property is equal to tsg, and either the value of the control's id property is equal to tsg_table or the value of the control's myType property is equal to table, UFT One uses a TSGTable test object to represent the control.

If the value of the custom control's className property is equal to tsg, but the value of the control's id property is not tsg_table and the value of the myType property is not table, UFT One calls the isTable JavaScript function to determine whether to use a TSGTable test object.

If the value of the custom control's className property is not equal to tsg, UFT One continues to the next Control element in the toolkit configuration file without calling isTable identification function.

<Control TestObjectClass="TSGTable">
    <Identification type="javascript" function="isTable">
      <Browser name="*">
        <Conditions type="IdentifyIfPropMatch" logic="and">
            <Condition prop_name="className" expected_value="tsg"/>
            <Conditions logic="or">
                <Condition prop_name="id" expected_value="tsg_table"/>
                <Condition prop_name="myType" expected_value="table"/>
            </Conditions>
        </Conditions>
        <Conditions type=" SkipIfPropMatch" logic="and">
            <Condition prop_name="className" expected_value="tsg" equal="false"/>
        </Conditions>
      </Browser>
    </Identification> 
</Control>

For information on the structure and syntax of the Conditions and Condition elements, see the Toolkit Configuration Schema Help.