Information in this topic applies to desktop applications only.

Connected and Self-Testing applications are deprecated. These technologies will be removed in one of the future releases of TestComplete.
To create test code that runs from within your tested apps, use TestLeft, a SmartBear functional testing tool for developers.

The TestComplete object model includes a great number of objects that let you implement sophisticated test scenarios. However, your testing framework may require processing that is difficult to implement using the TestComplete facilities though can be easier achieved within the tested application’s code.

TestComplete and its internal subsystems, including the object model, are COM-based. Thus, you can register a particular object of your application as a scripting object via the TestComplete COM engine. This will make the object’s methods and properties available in TestComplete scripts. Using this feature, you can, for instance:

Expose internal objects of black-box applications to TestComplete, or provide easier access to internal objects of Open Applications. In this way, you increase the degree of the application’s “openness”.
Create scripting objects that implement specific functionality needed in your tests.
Implement specific tests on the application side and call them from TestComplete via custom scripting objects. This approach goes hand-in-hand with Unit Testing.
And so on.

To extend the object model with custom objects, TestComplete provides a special extensibility manager. It is available in Connected Applications as the Manager object. To register the application’s object as a scripting object in TestComplete, you can use the manager’s AddName method:

ManagerObj.AddName(Name, Global, Obj)

Name - The name under which the object will be registered in TestComplete.
Global - Specifies whether the object should be global. Methods and properties of global objects can be called without specifying the object name first. Examples of global objects are BuiltIn and Utilities.
Obj - The object to be registered as a scripting object. This object must implement the IDispatch interface. If the desired object does not implement this interface, you will need a wrapper that implements IDispatch and provides access to the desired object. Objects of .NET applications can only be exposed via wrappers (see Creating Scripting Objects From C# Application Objects and Creating Scripting Objects From Visual Basic .NET Application Objects).

To unregister a specific custom object, call the manager’s RemoveName method:

ManagerObj.RemoveName(Name)

Custom scripting objects become available as top-level objects such as Sys, Log and others. You can access the object members using the common notation: object_name.member_name (or, simply member_name if the object is registered as a global object). You can call the object methods, obtain and set its property values the same way you work with standard TestComplete objects. At that, you actually call methods and properties of the corresponding object within the application. So, the processing is performed on the application side.

The following topics explain how you can create scripting objects from objects of applications created in different development tools:

Remarks

We would like you to pay special attention to the following specifics:

Custom scripting objects can registered in the current TestComplete session only. Therefore, you need to register your custom objects each time you run TestComplete.
Custom objects can only be registered when TestComplete is not running a script. If your application calls the Manager.AddName routine during script execution in TestComplete, an error will occur.
Since a custom object is a part of the application, its lifetime is determined by the application code. This means that the object only exists while the application is running. After you close the application, the object will become unavailable to TestComplete.
The scripting languages supported by TestComplete have different naming rules. Since the object can be called from a script written in any of these languages, the object’s scripting alias and the names of its methods and properties should match the naming rules of any supported scripting language. The easiest way to achieve this is to only use letters, digits and underscore characters in names and start a name with a letter.
It is possible to register a scripting object under the same name as the other TestComplete top-level object (for instance, Sys or Log). However, in this case the new object will overlap the standard object, so that the latter object along with its methods and properties becomes unavailable.

Creating Scripting Objects From Application Objects

Remarks

See Also