TestComplete uses two ways to identify objects.
- Default Object Naming – using the default object names given by TestComplete itself.
- Name Mapping – map application objects to custom names and then uses these names to refer to the objects in your tests.
TestComplete treats each process, window, control, etc. as an object. Objects can be either non-visual, such as system or processes, or onscreen, such as windows. Some onscreen objects have Window’s handles. For instance, normal controls have handles, while others do not. An object can have one parent and one or several child objects. Each child object has a unique name among its siblings.
Object tree model — Specifies which window model TestComplete will use to address windows: Flat or Tree.
The Flat model means that the direct children of a process are top-level windows and all other windows (controls) are children of the top-level windows, regardless of the actual parent-child relationship of these windows. This shortens the path needed to address child windows in scripts. The Tree model implies that TestComplete uses the actual parent-child relationship. In this model, child windows’ names are longer, but they are more natural.
The hierarchy of processes, windows and control objects are shown in the Object Browser panel. The top-level object of this hierarchy is System (Sys). Its children are processes that are currently running on the computer system. When you change the Object tree model setting of the main project, TestComplete updates the Object Browser panel so that it displays the hierarchy of the processes and windows in the appropriate manner.
TestComplete gives names to each process, window objects, which is used to address the object in tests. The object name depends on the object type, values of object properties, and on application type. By default, to form an object’s name, TestComplete uses values of object’s properties. In order for a property to be used in addressing an object, it must uniquely distinguish the desired object from other similar objects and remain unchanged during the application’s execution and between application runs. In general, no property meets all of these requirements, so TestComplete uses a combination of properties to identify objects.
For instance, to address processes it uses the name of the executable file that started the process and the process index;
to address windows it uses the window’s class name, window’s caption and index.
The object names typically include several components:
Process Name – TestComplete uses two parameters to identify processes
- The name of an executable file that starts the process. The file name is used without an extension.
- The index of a process instance. There can be several running applications with the same name in the system. In this case, the process index is used to distinguish one process instance from another. The first started process has index 1, the second – 2, and so on. The process index can change during the test run: if a process with a lower index is terminated, the higher indexes will be decreased, so the names of other processes are changed.
“Process(‘notepad’,2)” is the process name. In this ‘notepad’ is the name of executable and 2 is the index of process.
Window Name – The way in which TestComplete addresses windows in keyword tests and script code depends on whether the window is mapped or not. If the window is mapped, then TestComplete uses its mapped name or alias. Else, it uses the default window names.
Sys.Process(‘notepad’,2).Window(‘Notepad’,’Untitled – Notepad’, 1)
Window(‘Notepad’,’Untitled – Notepad’, 1) is the window name, where ‘Notepad’ is the Class name. ‘Untitled – notepad’ is the window caption and 1 is the index.
TestComplete uses the same as window for naming a control and other objects.
However using this way TestComplete lets us uniquely identify the objects, but there are some issues as well with default naming.
- The object name depends on object properties that are not persistent. For instance, window and control identification attributes (class name and caption) can change from one application build to another. To run your tests successfully, you may need to replace the old object names with new ones in the entire project before running the tests.
- Quite often, the object names are long and unreadable (for instance, it may be difficult to see which control has the following name:
Sys.Process('notepad').Window('#32770', 'Font', 1).Window('ComboBox', '', 3).Window('Edit', '', 1)).
To overcome with these issues, TestComplete has the Name Mapping project item, using which custom names can be assigned to objects.
Basically in name mapping you need to choose the desired object for mapping and specifying its properties and their particular values that the test engine will use for the object identification. These properties and values are stored in the corresponding name mapping item along with the custom object name which is used by TestComplete to identify the mapped object during test recording and playback:
- When TestComplete meets a custom name during the test execution, it calls the Name Mapping engine to search the object tree for the object having the specified properties, and once this object is found, it returns it to the test engine.
- When recording a test, TestComplete checks whether the object, that you are working with, is mapped and if the appropriate name mapping item is found, TestComplete records the mapped name or alias rather than the ordinary object name.
Once an object is mapped, it is available through the Namemapping or Aliases objects.