![]() | Note |
|---|---|
Hooking into subprocesses is not supported for Java applications. |
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 + 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.)
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.
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.
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 + to pop up the "Manage AUTs" dialog (Section 17.3.4). For Squish 3, click + 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 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.
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 + 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.
def main:
attachToApplication("attachableAddressbook")
snooze(1.0)
function main()
{
attachToApplication("attachableAddressbook");
snooze(1.0);
}
sub main
{
attachToApplication("attachableAddressbook");
snooze(1.0);
}
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)).