The object-driven testing (ODT) functionality is deprecated. Do not use it to create new tests. It will be removed from the product in one of the future releases. As an alternative, you can create custom classes in your scripts. For more information, see Alternatives to the ODT functionality.
The custom objects you create in the ODT project item not only holds testing data, but also controls the testing process. To simplify the control process, the project item provides specific means for filtering test data, for walking down the object hierarchy and running methods of each object and for selecting the methods to be run. These capabilities are useful for large projects that use lots of testing data. They save the time needed to handle object-driven tests. The current topic describes these means and explains how you can use them. It assumes that you are familiar with the basic concepts of the ODT project item described in the ODT Project Item topic.
In most cases, the hierarchy of custom objects has a tree-like structure. The root of this tree is the
ODT.Data object; the tree nodes are variables, custom objects, array items, etc. The test script and keyword test can walk the tree and call methods of objects stored in tree nodes. The main test will have to initiate the “walk”.
Let’s continue with an example: suppose that the application under test is a text processor and you need to test the Find and Find and Replace dialogs of this application. To obtain reliable results, each dialog should be tested on several files and using several sets of testing values. In addition, the operation each dialog performs can be tested using different conditions: the search can be case-sensitive or not, it can be performed in different directions (forward or backward), with enabled and disabled regular expressions, etc. The testing will include the following steps:
Once the Find dialog is tested using all possible testing values, the tests can continue with another dialog.
The hierarchy of objects that perform testing in the described way looks like this:
The order in which the objects are organized can be modified via the Move Up or Move Down commands of the context menu. This makes it possible to alter the walk-down path. You can move the items that belong to the same hierarchy level, but you cannot transfer an item to an upper or lower level. Also you cannot mix object-specific and class-specific properties and methods.
Objects of the upper levels will hold references to objects of lower levels. Methods of the topmost object launch the application and perform different initialization actions. Objects on the second level operate with testing files. Their methods open these files in the application under test. Objects of the next level show the Find and Find and Replace dialogs on the screen, etc.
Besides the code of the class methods, you need to create a script routine or a keyword test that walks down the tree and calls object methods at each level. As we mentioned above, the ODT project item provides a method that is used for this task:
ODT.Data.Run. It walks down the tree and processes each tree node in the following manner:
Runmethod checks each item of this array.
Runmethod “processes” this object in the following manner:
Runmethod processes this object (i.e. executes its methods and processes the properties) in the described manner. If a property holds an array, the method processes each item of this array in the manner described below. If a property holds an ordinary value, it is ignored.
ODT.Data.Run method you can perform the test very easy. Just write a script routine or a keyword test that calls this method.
Data groups, objects and arrays contain methods similar to
ODT.Data.Run. They differ from
ODT.Data.Run in that they start processing from the level to which the data group, object or array belongs, while
ODT.Data.Run processes all of the data groups.
The ODT project item offers specific means for excluding tree nodes from testing. Once the tree nodes have been excluded,
ODT.Data.Run will not process them. This is also applied to other
Run methods. The means for excluding are described in the following section.
By default, all data groups, variables, custom objects and arrays are included in testing. That is, the
Run method processes each of these elements. The ODT, Classes and Data editors include two means to exclude objects from testing: check boxes and data filters.
Check boxes allow you to include elements to and exclude them from testing by checking (unchecking) them in the ODT or Data editor. For instance, to exclude a data group, open the editor and uncheck the data group there. To include the data group in testing tasks, simply check it. The following icons indicate whether an element is included or excluded:
|The object is included in testing and all of its child objects are also included in testing. If the object’s icon does not have the element, the object is excluded from testing.|
|If an object contains the element in the icon, this means the object is included in testing, but at least one of its child objects (direct child, grandchild, great-grandchild, etc.) is excluded.|
|Grayed icon||The grayed icon, e.g. , means that the object is excluded from testing because one of its parent objects is excluded from testing.|
|Note:||The graphic elements described above can be combined with graphic elements added by data filters (see below).|
Besides data groups, objects and arrays, you can also exclude and include object methods in testing. Once you have excluded a method, it is not called by the
Run method. To exclude a method:
Note that if you uncheck an object method, you make it unavailable for the
Run methods only. You still can call this method in your scripts and keyword tests.
Checking and unchecking allows you to specify what objects and methods should participate in testing and what objects and methods should be excluded from it. If you use a lot of testing data and have lots of tree nodes, checking and unchecking can become an annoying task. To solve the problem, you can use data filters. Filters allow you to easily exclude objects from testing by unchecking the value of one of the object properties in the Filter dialog. Let’s illustrate this on a sample: suppose you have a class for testing the Find dialog. One of the properties of this class holds an array of
ClsReplaceData objects. The
ClsReplaceData objects hold testing values (that is, values stored in properties of this objects are entered into the dialog’s edit fields). Suppose there are several
FindText property holds the string bbb. We want to exclude these objects from testing. To do this:
ClsReplaceDataclass in the editor.
FindTextproperty. This will call the Filter dialog that lists all values stored in this property:
Uncheck bbb in the list. This will exclude all objects whose
FindText property stores the unchecked value. The
Run method will ignore these objects (it will not process the object’s properties and will not call the object’s methods). If you want to exclude objects in which the
FindText property holds either bbb, or extension, uncheck both bbb and extension in the dialog.
The empty string at the top of the dialog indicates that there are objects whose
FindText property does not hold any values. By unchecking this check box, you can exclude these objects from testing.
To check all values, press Select All. To uncheck all values, press Unselect All.
TestComplete uses the following icons to indicate that objects were or were not excluded by the filter. Note that “filter” graphic elements in object icons are combined with the and graphic elements (see above):
The object is excluded from testing because a filter is applied to one of its properties. The element indicates that the filter is applied to the object. The property whose value does not match the filter is marked with .
Since the “filter” graphic elements can be combined with “non-filter” elements, the following combination is possible: . It means the object is excluded by a filter and at least one of its child objects is unchecked.
|,||If an icon includes the element, it means that one or more child objects are excluded by a filter. For instance, the icon means the object is excluded by a filter and at least one of its child objects is excluded by a filter. means the object is included in testing, but one of its child objects is excluded by a filter.|
|Red frame||An icon with a red frame, e.g. , means that the object is excluded from testing because one of its parent objects is excluded by a filter. The icon contains . This means the object is checked in the editor and if you remove the filter, the object will be included in testing. means the object is excluded by the filter which is applied both to this object and to one of its parent objects.|
|,||The icon is displayed for class properties only. It indicates that you can apply a filter to a property. Pressing the icon displays the Filter dialog. For properties whose values do not match the filter, TestComplete displays the red filter icon ( in classes, - in objects). This allows you to easily find the property by which the filter excludes the object.|
When you uncheck values in the Filter dialog, you make objects unavailable for the Run methods only. You do not “disable” the objects. You can call their methods in scripts or keyword tests, modify properties, etc.
One important note: in order for you to be able to use filters, the testing data needs to be organized properly. For example, you can store testing values for the Find dialog using one of these methods:
Filters are applied to objects, but not to ordinary values. Therefore, you will not be able to use filters if you organize your data as a multidimensional array.
Note that data filters are independent of check marks, which you can set for each object in the ODT or Data editor. An object is excluded from testing if it is unchecked in the editor or if it is excluded by a filter. To include the object in testing, change the filter so that it “includes” the object and make sure the object is checked in the editor.
To specify a method as an Init:
To specify a method as an Init: