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. |
Connected and Self-Testing Applications contain imported script code that interacts with TestComplete through the TestComplete OLE engine. Note, however, that in order for the imported code to be able to simulate user actions (clicks, double-clicks, keypresses and others), TestComplete must be running a script. Otherwise, an error will occur. Also, all of TestComplete scripting objects, except for Sys
, are NOT available to Connected (or Self-Testing) Applications when a script is NOT running.
When you run your tests from Connected Applications, the ensuing test log does not provide you with screenshots captured during the test execution. It means that the Pictures tab of the test log is empty for such tests. This situation is caused by the fact that the Visualizer feature is disabled when you run your tests from Connected Applications. |
Before running the imported script code, you must ensure that TestComplete is running a script. There are two ways to do this:
Starting Applications From Script
To ensure that TestComplete is running a script, you can launch your Connected or Self-Testing Application from the script:
-
Call the imported script code from your source code. For instance, you can call it within a button’s
OnClick
event handler. -
Compile your application.
-
Open your project in TestComplete.
-
Add your Connected Application to the project’s tested applications list. For more information on how to perform this, see Defining Application to Test.
-
Write script code that will launch your Connected or Self-Testing Application and wait while it performs the testing actions. For instance:
JavaScript, JScript
function Test()
{
var p;
// Launches the Connected Application and obtains the process
// that corresponds to your Connected Application
p = TestedApps.Items[0].Run();
// Delays script execution while
// the Connected Application performs the testing actions
while(p.Exists)
aqUtils.Delay(500);
}Python
def Test(): # Launches the Connected Application and obtains the process # that corresponds to your Connected Application p = TestedApps.Items[0].Run() # Delays script execution while # the Connected Application performs the testing actions while(p.Exists): aqUtils.Delay(500)
VBScript
Sub Test
' Launches the Connected Application and obtains the process
' that corresponds to your Connected Application
Set p = TestedApps.Items(0).Run
' Delays script execution while
' the Connected Application performs the testing actions
While p.Exists
aqUtils.Delay 500
WEnd
End SubDelphiScript
procedure Test;
var
p : OleVariant;
begin
// Launches the Connected Application and obtains the process
// that corresponds to your Connected Application
p := TestedApps.Items[0].Run;
// Delays script execution while
// the Connected Application performs the testing actions
while p.Exists do
aqUtils.Delay(500);
end;C++Script, C#Script
function Test()
{
var p;
// Launches the Connected Application and obtains the process
// that corresponds to your Connected Application
p = TestedApps["Items"](0)["Run"]();
// Delays script execution while
// the Connected Application performs the testing actions
while (p["Exists"])
aqUtils["Delay"](500);
} -
Make sure this code is called when running the current TestComplete project.
-
As you can see, the script runs until the Connected (or Self-Testing) Application is closed. In order to stop the script run from the Connected Application, use the
Runner.Stop
method. This method notifies TestComplete that the run is over, and refreshes the test log so that it displays the latest test results.
Using the RunTest and StopTest Routines
To switch TestComplete to the script-running state, you can use the RunTest
routine. This routine is located in the files that you include in your Connected or Self-Testing Application (script.h, TCConnect.pas, TCConnect.bas and others).
The routine uses the following parameters:
RunTest(LogName, ProjectName, SuiteName)
The routine does not return a value. All parameters are strings and all of the parameters are required:
-
LogName - Specifies the name of the item in the test log. When running tests from TestComplete, it uses the name of the running project item, project or project suite to name the root item in the test log. Since the
RunTest
routine does not require running a project or a project item, TestComplete needs a string to be used as the log item’s name. -
ProjectName - Specifies the name of the project where messages will be posted to after they are generated during the imported codes execution. The project name must be the name that is displayed in the Project Explorer panel, not the project’s file name.
-
SuiteName - Fully qualified file name of the project suite that contains the project specified by the ProjectName parameter.
Note: | If your Connected (or Self-Testing) Application is a .NET application, call the RunTest routine as a method of the Connect class -- Connect.RunTest . |
The RunTest
routine does not require a running test. It automatically switches TestComplete to the script-running mode and prepares the test log for receiving messages. Furthermore, the routine does not even require TestComplete to be running. If TestComplete is not running, it will launch itself, load the specified project suite and initialize the engine and test log.
The RunTest
routine only switches the state and prepares the log, it does not execute test items defined in the project. You need to call the routine before calling the first instruction of the imported script code.
Due to some specifics of TestComplete subsystems, some objects like Log
, ADO
, BDE
, Utilities
and others may become available only some time after the test execution has been started. So, if you have problems with calling methods of these objects, it is recommended that you insert a short delay after the call to the RunTest
routine. The name of the function that delays the execution depends on the program language you use to create your Connected Application. For instance, in Visual C++ you can use the Windows API Sleep
function.
To stop the test run initiated by the RunTest
routine, you should call the StopTest
routine or call the Runner.Stop
method. The StopTest
routine is just a wrapper over Runner.Stop
. It does not use any parameters and does not return any value. It is defined in the same file as RunTest
.
Note: | If your Connected (or Self-Testing) Application is a .NET application, call the StopTest routine as a method of the Connect class -- Connect.StopTest . |
The RunTest
and StopTest
methods work together to start and stop testing from Connected and Self-Testing Applications. RunTest
is called before executing the first instruction of the imported script code and StopTest
is called to command TestComplete to stop the test run. The following code snippet demonstrates a typical use of the methods:
RunTest("MyLog", "MyProject", "C:\Work\MyTest\MyProjectSuite.pjs")
Sleep(500) // Optional delay (500 milliseconds in this example)
...
// Imported script code
...
StopTest()