|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 entire TestComplete engine is an OLE server that can be accessed through the TestComplete user interface or run directly from your application’s code using the application’s language, classes, types and constant definitions. You can also use your development tool’s IDE, including its debugger.
By linking one file into your application’s source you can manage the TestComplete OLE engine connection and expose the entire TestComplete OLE interface to your application, but in its own language. This is the same interface that TestComplete UI uses, including
Objects and other program objects. An application with this file linked is called a Connected Application.
Connected Applications use the TestComplete engine to execute test scripts in the same way scripts are executed in TestComplete. This technology appeared in early TestComplete versions and is obsolete now. Below is a list of reasons for using Connected Applications in the past and their alternatives in TestComplete 14:
More control over test execution. One of the reasons to create a Connected Application instead of using TestComplete itself was situations where you needed more control over the test execution. For example, in Connected Applications you could create specific dialogs to accept user input, implement complex test logic, check for the presence of certain dynamic link libraries and wait-for conditions and so on. As TestComplete evolved, it got similar features: user forms, checkpoints and many others.
Access to internal methods and properties of tested applications. In the past, certain objects and members of tested applications remained inaccessible to TestComplete, while built-in test code could call any private class or function that was visible to it. However, now TestComplete can see deep into tested applications and can provide test scripts with access to protected and even private members.
Unit testing. This was one more reason for creating Connected Applications. Connected Applications could expose their objects as top-level scripting objects to TestComplete. So, you could import specific application objects to the TestComplete object model and use them in scripts at your desire. Now TestComplete can expose even private object members. So, to make your unit test harness accessible to TestComplete, you do not have to make your application a Connected one.
As you can see, all the benefits that Connected Applications provide are now available when using TestComplete. The Connected Application technology has become obsolete and will be removed in one of the future product versions. We do not recommend using it for creating new tests.
Connected Applications are deprecated. We do not recommend using them for creating new tests. The topics below explain how to create Connected Applications in various development tools. They are for reference for those who have not stopped using this technology yet:
Note for Windows 10, Windows 8, Windows 8.1 and Windows Server 2012 users: Currently, TestComplete needs specific preparations to be able to work via COM on Windows 10, Windows 8, Windows 8.1 and Windows Server 2012. Since Connected Applications work with TestComplete via COM, you may need to change the privileges of your application or TestComplete in order to be able to run tests. For detailed information on the needed preparations, see the Configuring Manifests on Windows 8 and Later Operating Systems topic of the Working With TestComplete via COM section.
Note for TestComplete 64-bit users: To work with 64-bit TestComplete, you must use the
TestComplete.TestCompleteX64Application COM object. To learn more, see Working With TestComplete via COM - Overview.