16.8. Hooking into the Sub-Processes run by an AUT, and Attaching to Running Applications

16.8.1. Recording the Sub-Processes started by the AUT
16.8.2. Attaching to Running Applications
[Note]Note

Hooking into subprocesses is not supported for Java applications.

16.8.1. Recording the Sub-Processes started by the AUT

By default, Squish hooks into the application which is started by the test and ignores any sub-processes that the AUT may create. However, Squish supports the testing of programs started as sub-processes, providing you tell Squish about them using the steps described here.

The first step is to make a change to the test suite's settings. For the Squish 4 IDE, click the project's Suite Settings to make the Settings view (Section 17.2.13) appear, then check the Hook into sub-Processes started by the application checkbox—you may have to scroll down to see the checkbox. For the Squish 3 IDE, click Test Suite+Settings to get the Test Suite Settings dialog and click the General tab's Hook into Sub-Processes started by the Application checkbox.

The second step varies between Unix-style operating systems and Windows.

For Windows it is necessary to make some small changes to the AUT's source code so that Squish can successfully hook into programs that are started as sub-processes. Essentially this means running a wrapper program (dllpreload.exe, supplied with Squish), that actually starts the sub-process's program. The change can be effected so that it is only active during testing.

For example, suppose that the AUT had the following source code to start a sub-process:

QProcess process;
process.start("subprogram.exe");

To change this to work with Squish, change the AUT in two ways. First add a new command line argument, say --testing, that when given sets a global Boolean, say, TESTING to true. Now update the code that calls the subprocess as follows:

QProcess process;
QStringList commands;
#ifdef Q_OS_WIN32
if (TESTING)
    commands.append("dllpreload.exe");
#endif
commands.append("subprogram.exe");
process.start(commands[0], commands.mid(1));

When TESTING isn't defined the commands string list will only contain one item ("subprogram.exe"), and commands.mid(1) will harmlessly return an empty list.

To make the change effective, in the Settings view (Section 17.2.13) (or for Squish 3, the Test Suite Settings dialog), add --testing to the AUT's Arguments.

Now, when Squish executes the AUT on Windows and the sub-process is started, what will actually happen is that Squish's dllpreload.exe program will be started with the intended application (e.g., subprogram.exe) as its first argument, and any other arguments passed as arguments to the intended application as normal. This means that the AUT and sub-process's behavior will be exactly what it was before.

For Unix-like systems such as Linux and Mac OS X the sub-process(es), which are started by the AUT and which Squish should hook into, simply need to be whitelisted, since Squish will only hook into known (whitelisted) applications. Whitelisting is done simply by adding the programs to be run as sub-processes as AUTs known to Squish or by adding their paths as AUT paths. Adding an AUT or AUT path can be done on the command line or through the Squish IDE. See AUT Paths and Mapped AUTs (Section 16.4.2) for details.

With the preparations just described in place, Squish will be able to record and play back actions that take place in sub-processes as well as in the AUT proper.

When recording sub-processes, the test script will contain calls to the waitForApplicationLaunch function. This function returns an ApplicationContext object for each application started as a sub-process. (See also, Application Context (Section 16.1.3.10).) Using context objects makes it possible to tell Squish which application it should be interacting with at various points in the test script's execution. (See How to Use ApplicationContext Objects (Section 15.1.10.2) for details about working with application contexts.)

16.8.2. Attaching to Running Applications

16.8.2.1. Overview

Squish's default behavior is to automatically start the application you want to test, and to terminate the application once the test case is finished. But it is also possible to test an already running application by attaching to it. One important difference when attaching is that at the end of the test case Squish does not terminate the application it attached to.

One benefit of attaching is that it allows you to test your application with the squishserver running on another machine. However, the attaching approach also suffers from an important limitation: you can have only one squishserver attached to your application at a time.

Using the attaching approach is a three step process: first start the AUT; second, register the AUT; and finally, attach to the AUT from a script. We'll now discuss each of these steps in turn.

16.8.2.2. Start the AUT

In order for Squish to be able to connect to the AUT, you must start the AUT using Squish's startaut (Section 16.5.6) command line tool.

Usage:

startaut --port=port aut [aut-command-line-options]

You must specify a network port number as the argument to the --port option. The AUT listens on this port number for a connection from the squishserver.

It is important that the --port option is given before the AUT because any aut-command-line-options options specified after the AUT are passed as options to the AUT and are not used by startaut (Section 16.5.6).

Example:

startaut --port=5900 addressbook

Once the AUT is running we are ready to connect to it. But first we must register the attachable AUT in order to be able to access it from test scripts.

16.8.2.3. Register the AUT

Just the same as with AUTs that are started and terminated by Squish, AUTs that are attached to must be registered. This is easily done using the Squish IDE. For Squish 4, click Squish+Manage AUTs... to pop up the "Manage AUTs" dialog (Section 17.3.4). For Squish 3, click Edit+Preferences to pop up the Preferences dialog, then click the Server Settings tab. Select the Attachable AUTs entry (which might be near the bottom of the tree view), and press the Add... button. This will pop up the Add Attachable AUT dialog. Use this dialog to enter the name of the AUT you want to be able to attach to—the name is just an acronym to stand for the AUT and for use in test scripts. Also, you must set the port number to the same one that you used when starting the AUT with startaut (Section 16.5.6). In addition, you can specify the hostname—this is necessary only if you want to run the AUT on a different machine from the one that runs the squishserver.

16.8.2.4. Attaching from a Script

First you must tell Squish not to automatically start the AUT you wish to attach to when a test case is run. For Squish 4, click the Suite Settings item in the project tree, and in the Application Under Test (AUT) section, change the Application combobox's item to the <No Application> item. For Squish 3, click Test Suite+Settings to pop up the Test Suite Settings dialog, and on the General tab, change the Application combobox's item to the <No Application> item.

Now Squish will not start up the AUT for test cases in this test suite. We have already seen earlier how to start the AUT using the startaut (Section 16.5.6) application. But to be able to connect to the application and interact with it our test script must attach to it. This is done by putting a call to the attachToApplication function in the test script, and passing it the arguments it needs to attach to the AUT. In fact, the only mandatory argument is the name we gave the AUT when we registered it.

Just as we use the attachToApplication function to attach to a running application, similarly we can use the startApplication function to start an application. And both these functions return an application context object (see Application Context (Section 16.1.3.10)).

It is possible to record a test script if you are attached to an AUT. But since Squish did not start the AUT, it isn't possible to simply click the Record toolbar button. Instead you must write a tiny test script that just has a simple main function and a call to the attachToApplication function.

Python
def main:
    attachToApplication("attachableAddressbook")
    snooze(1.0)
JavaScript
function main()
{
    attachToApplication("attachableAddressbook");
    snooze(1.0);
}
Perl
sub main
{
    attachToApplication("attachableAddressbook");
    snooze(1.0);
}
Tcl
proc main {} {
    attachToApplication "attachableAddressbook"
    snooze 1.0
}

Now place a breakpoint on the line with the snooze function. If you now play back the test script, Squish will attach to the AUT and start executing the test script. But as soon as Squish reaches the call to the snooze function it pauses execution thanks to the breakpoint. Now you can choose Record to extend the test script by recording whatever actions you like. When you are finished, simply press the Stop Recording toolbar button in Squish's control bar and the new test script will become visible in Squish's editor. (see How to Record After a Breakpoint (Section 15.2.2)).