Testing GUI software can often start sub-processes. These can be either background services which are not directly visible to the user, or they can show an additional UI. The Squish GUI Tester allows the user to control which of the sub-processes will be hooked and which are to be ignored.
Squish for Qt
When a Qt Application Under Test (AUT) is started using the
startApplication() script API, Squish for Qt hooks only a single process by default. If the tested application uses a sub-process showing a GUI, you can enable the relevant option on the test suite settings page in the Squish IDE. This will make the additional GUI accessible to Squish.
With the above option enabled on Linux or macOS systems, Squish for Qt attempts to hook every sub-process spawned by the AUT. In case the sub-application does not show a GUI or uses an unsupported toolkit, loading the Squish hook into it is superfluous and may cause some unwanted side effects. In most cases it will be as benign as slightly increased memory consumption, but sometimes may include performance problems, unusual application behavior or even application crashes. Applications that are most exposed to such issues are:
- Applications that use a different version of the Qt library than the main AUT;
- Terminal applications that use only the core part of the Qt library and don’t initialize the GUI-related modules.
Regardless of the side effects, it is best to limit Squish for Qt hooking to affect only the required applications. Squish for Qt already blacklists a number of common UNIX utilities like
hostname. Squish ignores such applications entirely. If your AUT starts any sub-processes that are erroneously hooked, you can add their executable names to the
etc/ignoredauts.txt file in the Squish for Qt installation. The name should include the full filename without its filesystem path. Such processes will be ignored by Squish as well.
# example ignoredauts.txt file ping perl my_aut_loader
Ignoring certain applications may be useful even when the sub-process hooking is disabled. In such configurations, Squish for Qt waits for a single connection from a hooked AUT. Once that happens, it ceases to hook further processes. However, some software requires a startup script or an additional application that runs prior to the main process and is responsible for starting it. Such an application may even include a simple GUI, i.e. a splash screen. In order to avoid mistaking such processes for the main AUT, the name of the script interpreter or the startup executable file name should be added to the
etc/ignoredauts.txt as well.
Squish for Qt on Windows
Due to limitations of the Windows operating system, automatic hooking of all the Qt sub-processes is not possible. Please follow the Squish manual to hook additional Windows applications using the
dllpreload executable. Applying the treatment described in the manual selectively allows a large degree of control over the hooked processes.
Squish for Windows
Squish for Windows always hooks all the sub-processes of the AUT. Due to the non-invasive nature of the application wrapper, it should not cause any unwanted interference. However, processes that are irrelevant to the test may still clutter the object tree and litter the recorded test cases with unnecessary test instructions. Such processes can be ignored by adding their executable names to the
etc/winwrapper.ini file under the
Blacklisted Processes option.
[...] # The Blacklisted Processes key is used to identify executables # that the Windows wrapper should not attempt to hook up (for # recording or playback). The matching is done on the filename of # the executable (but case-insensitively). # # Example: # # Blacklisted Processes="notepad.exe","mspaint.exe" Blacklisted Processes="perl.exe","my_aut_loader.exe"
Precise control over the Squish hook can help avoid many problems. It keeps the test suites clean of unexpected and unwanted object names and test instructions. It makes navigating the Application Objects Tree easier. And in rare cases it prevents Squish from interfering with the tested software. Test writers should always strive to limit the scope of the Squish hook to the required minimum.