About Open Applications

When testing foreign, unprepared desktop applications, TestComplete uses the Windows API to interact with Windows objects that are controlled by the application. This is called black-box testing. See Different Ways of Testing.

TestComplete can also search for tested controls on the screen using control images. It is image-based testing. By default, TestComplete records image-based tests for unprepared Android applications. You can also create such tests for desktop, web and iOS applications.

We recommend that you avoid black-box and image-based testing if it is possible. The deeper the interface between the application under test and TestComplete, the more clearly you can create your tests. Testing from the outside, but with a better view of the inside, is called white-box testing. Open Applications are applications instrumented for white-box testing under TestComplete. Open Applications provide access to their internal objects, methods and properties, so you can work with them from tests.

How “open” the application becomes to TestComplete depends on both the tool and what other options you choose to use:

• .NET Open Applications provide access to public, protected, private, internal and protected internal properties and methods.

• WPF (XAML) Open Applications give access to private, protected and public fields, properties and methods.

• In all cases, Open Applications make all ActiveX elements accessible externally. Thus, for Microsoft Visual Basic Open Applications, all methods and properties of applications’ forms and controls become accessible.

• For Visual C++ Open Applications, and for C++ source in C++Builder Open Applications, TestComplete uses specific wrapper classes for MFC objects. These wrappers only expose public class elements, and of course only for the classes to which they apply.

• Delphi Open Applications make all published properties accessible to TestComplete. The same applies to the Object Pascal code in C++Builder Open Applications.

• For Open Applications created in Visual C++, Delphi and C++Builder, the Debug Info Agent™ provides deeper access: the Agent provides scripts with access to all class members of Open Applications - public, published, protected as well as private. Compiling for the Agent is the only way to make these applications truly “open” for external testing.

• Java Open Applications and JavaFX Open Applications give the test engine access to public, protected and private methods and fields of these applications’ internal objects.

• Oracle Forms give the test engine access to their internal objects and to the objects' public, protected and private properties and methods.

• Flash and Flex Open Applications give the test engine access to public methods and properties of these applications’ internal objects.

• AIR Open Applications give the test engine access to public methods and properties of these applications’ internal objects.

• Qt Open Applications provide access to public properties and methods. In addition, if the Debug Info Agent™ is enabled, it provides scripts with access to protected and private properties and methods. Note that, the Agent will make protected and private properties and methods accessible to TestComplete only if the Read debug information for statically linked libraries option is enabled (for detailed information, see Project Properties - Debug Agent Options).

• Silverlight Open Applications provide access to public properties, fields and methods of these applications’ internal objects.

• Android Open Applications provide access to their internal objects and to their public, protected and private methods and properties.

• iOS Open Applications provide access to their internal objects and all of their methods and properties.

• Xamarin.Forms Open Applications provide access to their internal objects and to all of their methods and properties.

• MSAA Open Applications expose objects, methods and properties provided by the application’s embedded accessibility information (the IAccessible interface implementation). This applies to Sybase PowerBuilder, Microsoft FoxPro and Microsoft Office Access applications, as well as to Microsoft Office InfoPath forms.

• UI Automation Open Applications created with Win32, .NET Windows Forms and WPF UI frameworks use UI Automation providers to expose information about the application's UI objects, their methods and properties.

• TestComplete also has access to methods and properties of web page elements. To obtain access, there is no need to change the web page. You just have to install the Web Testing plugin. See Classic Web Testing.

Please pay special attention to the following: Some properties, methods and fields of Open Applications may be unavailable to TestComplete. For more information on this, see Object Properties, Fields and Methods That Are Unavailable to TestComplete. By default protected and private properties are not displayed in the Object Browser and other TestComplete panels and dialogs. For more information on this, see Access to Properties. To make these properties visible, enable the Show hidden members option in the Engines - General Options dialog. If you work with Microsoft Visual Studio 2005 (v. 8.0) you should install Service Pack 1 for it. Visual C++, Delphi and C++Builder Open Applications that were compiled for TestComplete 6 and earlier may function incorrectly in TestComplete 15. To learn how to port these applications to TestComplete 15, see Migrating Projects Created in Earlier Versions to TestComplete 15. Testing Open Applications in the RunAs mode requires that TestComplete be running under an administrator account that has the Default Access Permissions. For more information, see Settings for Testing Open Applications in RunAs Mode.

Self-Testing Applications that only access themselves can also be compiled as Open Applications. Some elements may be more easily accessed through Open Application support than from the source code of an application. The Debug Info Agent™ is the only way for application code to make use of its own debug information.

To indicate that an application is Open, TestComplete displays the icon next to its process in the Object Browser. Exceptions are Visual C++ applications, Delphi and C++Builder applications developed with the CLX library, Android applications and applications that contain objects exposed by the MSAA or UI Automation engine -- their processes are not marked with this icon.

You can check if an application is Open or not by expanding its process node in the Object Tree and exploring the child nodes -- if they have special glyphs (such as or ), the application is Open; otherwise it is “black-box”. For more information on glyphs used in the Object Tree, see Types of Displayed Objects.

An Open Application, with or without Agent support, can be run as a standard, “closed” application by putting NotOpenApp, -NotOpenApp or /NotOpenApp in its command line. Similarly, an application compiled for the Debug Info Agent™ can be run as a plain Open Application by putting -DisableDebugAgent, /DisableDebugAgent or \DisableDebugAgent in its command line, or by clearing the Enable Debug Agent option in Debug Agent Options.

In your tests, you can call internal methods and properties of Open Applications’s objects in the same way as you call those provided by TestComplete, that is, using the obj.member_name notation.

The following code shows how to access objects in Open Applications. It changes the caption of the button on a C# Open Application form. In the example below, Form1 and Button1 are objects of the tested application; Text is the “native” property of the .NET System.Windows.Forms.Button object. For more information on addressing objects in Open Applications, see Addressing Objects of Open Applications.

p = Sys.Process("OpenApplicationName");
p.Form1.Button1.Text = "New Caption";
# You can also use 
p.WinFormsObject("Form1").WinFormsObject("Button1").Text = "New Caption";

Access to internal objects, methods and properties gives you a chance to create more flexible and powerful tests. However, calling internal methods and properties may also cause problems, namely:

• Functions that reside in an Open Application may display modal windows. So, if you call these functions from your test, the test will be paused until the function returns. This may cause problems with testing the modal window displayed by the function. For more information on this problem and on how to resolve it, see Testing Modal Windows.

• You can call any object method in tests, but it is not recommended to call object constructors. Calling these may cause errors.

Note also that the application may be busy when you call an application’s internal method or property from script code. In this code, the test will be paused until the tested application starts executing the method or until the time limit specified by the project’s Method invoke timeout property is over. See Calling Methods and Properties of Open Applications' Objects.

TestComplete includes a number of sample Open Applications created in various development tools. For more information, see --

• Desktop Open Application Samples

• Mobile Open Application Samples

• Web Open Application Samples