Tip: Setting up Squish to attach to running applications in a distributed environment

Tip: Setting up Squish to attach to running applications in a distributed environment

There may be occasions when you want to keep your application running across multiple tests. For these cases, Squish provides the « startaut » tool. While its name has the word ‘start’ in it, this tool is very powerful, and, in the case of  « startwinaut »,  can also be used to help Squish attach to an already running application (see the option --window-title=). startaut needs to be used in coordination with a squishrunner and squisherver, to open a ‘hook’ IP server port for interacting with the AUT. While running all these processes on the same machine is known to work, so does running them on separate machines. The latter is a solution that helped numerous users who were not aware it was possible, so that is the focus of this article.

We can identify 3 possible setups:

  • Basic
  • Separate squishrunner from squishserver
  • Separate startaut from squishserver/runner

Note: We will describe the partition of the tools among multiple machines. Things like how to use/start/configure these tools won’t be discussed here.

Basic setup

This setup is the one described in our documentation and is the most commonly used by testers when developing tests that need to attach to a running application. This allows for fast feedback and interaction with the application, helping/easing the development of tests as it allows you to record snippets without replaying the full test case.

Separate squishrunner from squishserver

This setup is the most commonly used when testing applications on remote machines where the squishserver can start and stop the AUT. We could extend this diagram to have a squishrunner from “Machine A” connecting to a squishserver on a “Machine C”, leading to the parallel execution shown in a previous blog article.

Separate startaut from squishserver/runner

The advantage of this setup is that it allows you to restart the device/machine on which the application is running (given you are detaching from the script before doing so) unlike the other two setups. This approach is mostly used for testing an application that is always running on an Embedded device, for example.

Both setups rely on a careful configuration of each tool: adding the attachable AUT information in the squishserver, running startaut* to setup a hook server, and using the correct network (IP, Port) information in test scripts to attach to the application. You can find good resources on this topic in our blog , knowledge base article or manual.


  1. ManikandanJayararman 1 month ago

    Hi ,

    I was trying from Machine A (squish runner) to attachToApplication XYZ in Machine B(squish server is running). which is already running along with other softwares in Linux Target.
    Thanks in advance,
    Manikandan Jayaraman

    • Author
      Thomas Leifer 1 month ago

      Was the application XYZ started via the “startaut” tool ? If yes then please contact the support so we can investigate this together further.

  2. manikandan jayaraman 1 month ago

    No XYZ not started with ‘startaut’ because XYZ + some argument is part of system startup app so we don’t want to start specifically with additional command line argument. So need to attach to existing (running application).
    Thanks in advance,
    Manikandan Jayaraman

  3. Milind 1 month ago

    Regarding Separate startaut from squishserver/runner: Can we use this to test chrome apps on chrome book.
    We have a specific requirement to test our chrome app on chrome book OS only. So can i start my squish runner and server on win machine and start AUT on chrome book will that work? if yes can please send me the steps

Leave a reply

Your email address will not be published. Required fields are marked *