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.
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.
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 Default Web Testing.
|Please pay special attention to the following:
|Note:||It is also possible to expose the application objects to TestComplete by registering them in the TestComplete object model. The exposed objects become available as top-level scripting objects and can be used in scripts in the same way as standard objects (for instance,
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.
|Tip:||An Open Application has more elements than a “non-open” one, therefore obtaining the information for it requires a little more time compared to a standard application. If the number of Open applications is quite large, then the performance of TestComplete is slow. To increase the performance you can filter out “unnecessary” Open Applications. In the Process Filter Options page of Project Properties you can select which applications should be treated as Open.|
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
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,
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";
p = Sys.Process("OpenApplicationName"); p.Form1.Button1.Text = "New Caption"; # You can also use p.WinFormsObject("Form1").WinFormsObject("Button1").Text = "New Caption";
Set p = Sys.Process("OpenApplicationName")
p.Form1.Button1.Text = "New Caption"
' You can also use
p.WinFormsObject("Form1").WinFormsObject("Button1").Text = "New Caption"
p := Sys.Process('OpenApplicationName');
p.Form1.Button1.Text := 'New Caption';
// You can also use
p.WinFormsObject('Form1').WinFormsObject('Button1').Text := 'New Caption';
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 --
Debug Info Agent
Object Browser Naming Notation
Calling Methods and Properties of Open Applications' Objects
Working With Application Objects and Controls
Testing Modal Windows
Desktop Open Application Samples
Mobile Open Application Samples
Web Open Application Samples
Object Properties, Fields and Methods That Are Unavailable to TestComplete
Access to Properties
Testing Android Open Applications