Automating Multi-Process Applications using Squish for Qt

Many modern Qt applications employ a multi-process architecture. In such scenarios, the graphical user interface isn't rendered by a single process. Instead, multiple processes are used, each being responsible for a certain part of the user interface. A central, typically very simple, composer process is then used to compose the final image to be shown on the screen.

This means that a GUI testing setup should be able to consider multiple processes as a single application, hooking into each of them. That way, interactions and verifications done to any part of the GUI can be recorded and replayed, irrespective of which process the GUI is rendered by.

At the same time, there are many cases in which sub-processes shuold not get automated - e.g. those which draw no user interface at all. Cluttering the test script with unneeded waitForApplicationLaunch statements can slow down test execution for now reason and makes the GUI test dependent on implementation details of the AUT.

Thus, it's important to have very fine-grained control over which sub-processes a professional GUI testing tool considers for automation. This article explains how to include or exclude certain processes when deciding whether Squish should hook into them.

Detecting Sub-Processes Launched by an Application

By default, Squish for Qt only automates the application which was launched via Squish. Any sub-processes are ignored. This can be changed via the Squish IDE: in the Test Suite Settings section of your test suite, open the AUT** section. There's a check box that says Hook into sub-processes launched by the application. Checking this box will make Squish also consider sub-processes for automation.

However, depending on the operating system at hand, further configuration might be needed.

Explicit Opt-In On Windows Systems

On Windows, hooking is "opt-in": we explicitly need to enable sub-process hooking for those child processes which are relevant to test automation.

The easiest and least-invasive approach involves replacing your executable binary with a tool shipped with Squish:

1. First, append an underscore to your executable's base filename. So if your AUT spawns a child-process which is called mychildapp.exe:

c:MyApp> rename mychildapp.exe myapp_.exe

2. Next, copy Squish's own tool, known as dllpreload.exe, into the filename of the original executable:

C:MyApp> copy SQUISHDIRbindllpreload.exe mychildapp.exe

After doing this, all invocations of mychildapp.exe will automatically cause mychildapp_.exe to be executed which is then instrumented by Squish. Please see the Squish Users Guide for more on this - the guide also discusses alternative approaches to hooking into Windows processes.

Inclusion & Exclusion Lists On MacOS and Linux Systems

On macOS and Linux, enabling the detection of sub-processes in the Squish IDE is all that's needed. Ticking the check box will make Squish hook into all sub-processes. However, sometimes you would like to ignore some (or most) of the child processes. Luckily, this can be configured fairly easily using two configuration settings.

• It is possible to have Squish automate just known sub-processes of AUTs. To do so, put the line

USE_WHITELIST=1

into the suite.conf file of a test suite. This tells Squish that only 'mapped' applications are to be hooked. These can be set from the IDE, in Server Settings -> Mapped AUTs, or from the command line. For example, to register myapp in /usr/local/bin as a mapped AUT, execute:

$ bin/squishserver --config addAUT myapp /usr/local/bin

All processes which are not registered in squishserver will be ignored.

• Editing a text file in SQUISHDIR/etc/ignoredauts.txt allows you to specify that certain executables are to be ignored by Squish. Each entry should be on a separate line. See the users guide for further information.

This is useful in case the set of sub processes is unknown, but there are a few known child processes which you explicitly want to ignore.