Running Connected and Self-Testing Applications

Applies to TestComplete 14.92, last modified on September 16, 2021
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 Sub

    DelphiScript

    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()

See Also

Connected Applications - Overview
Self-Testing Applications

Highlight search results