Squish

Hi,

AFAIR, 6.2 is too old to have a pre-built package for macOS ARM.

I am currently in contact with Squish's QA support, will post the solution here if/when we find it.

In case you want to access to file on remote system (where squishserver is running),
you should access them via functions offered by "remotesystem" object.
For more information regarding this object please refer to the following documentation.
https://doc.qt.io/squish/squish-api.html#remotesystem-object

As workaround to overcome native file dialog, please refer to the following Knowledge Base article.
https://kb.froglogic.com/squish/qt/howto/automating-native-file-dialogs/

Yes, import urllib.request is the correct one. But I used import urllib just to reproduce the fatal error while running the squish test. urllib is not the concern of this topic. I want to discuss the exit code of squishrunner with --retry 1 whenever there is a fatal error. I would expect the non-zero exit code but it returns 0.

Looking into this further, I think "import squishtest" is what we need.

We will look into compiling the "squishtest" module under QNX.

I got it running after inserting 2 times the omitted duration template parameter: long

Hi Barak,
I hope you were able to solve the issue by now. Just in case you are still struggling, I would need to know a bit more about your setup, the Squish package you are using, and the Qt libraries used by your application.

First of all, you need to ensure that you are using a Squish package that is compatible your your application:
https://doc.qt.io/squish/installing-from-binary-packages.html#choosing-the-correct-squish-package

If you think that you choose the right one but the problem still occurs, please share the squishserver logs generated after you start the application under test via Squish.

Hi Axel,

Thank you for your reply.

I checked my Qt packages, and libQt5Widgets is indeed installed, but the issue persists. I decided to reinstall my environment, including qtcreator-8.0.2 (Qt version 5.15.0 (gcc_64)) and squish-for-qt-8.0.0.

Now, Squish works within QtCreator, meaning that it still doesn't connect with other applications. The recording option can only capture and generate scripts of my actions inside QtCreator but not for the applications run by QtCreator. Thanks for your help.

Hi @clanhuth,

Thanks for the advice! I will look into this.

Cheers,
Bo

To test the effect, you need to add synchronization and verification. For example, if a button X appears (and is enabled and ready for interaction) after clicking button A, then, after letting the script click on button A, you could use waitForObject() to verify that button X exists and is "ready". However, this kind of object verification is implicit when you record a click on button A, then on button X, because Squish records waitForObject() (and the like) calls for mouse clicks automatically.

Currently you need to compile or cross-compile Squish's Qt support on/for/to the desired target architecture. (In the future there will be Squish for Qt binary packages for some Linux variants for ARM based systems.)

For compiling you need the Squish for Qt sources. These need to be enabled in the Squish GUI Tester subscription license that you are using. Please contact Squish technical support for this.

For cross-compiling you need the Squish for Qt sources for cross-compilation. To enable these, the respective license option needs to be enabled in your Squish GUI Tester subscription license. If you do not see respective downloads in the download area at the Customer Portal (https://account.qt.io), then please contact your account manager at the Qt Group regarding this.

The readiness check in Squish for Qt for QML objects determines that the object is not ready for interaction, because it is not visible/accessible on the screen, because its parent clipped it away. What this means, and what to do, probably depends a lot on the situation, which I cannot derive from the information that you have provided.

The script code that you provided should not result in this error, because it does not contain a waitForObject() call.

If you only want to look up an object for something else than interaction, you can consider using the findObject() function, which does a one-time search for the object, and it does not perform the "readiness" check. It will throw an error if no matching object can be found, or return the reference to the found object.

Squish has no explicit support for this, yet. However, the support for Microsoft UI Automation (UIA, MS UIA) in "Squish for Windows" may be able to identify objects, even though it will not give access to the native API of the individual controls (something that Squish for Windows offers for Windows Forms and WPF based controls). If this would be sufficient for automation depends on the actual requirements, and which controls are identifiable that way.

One can check with Microsoft's "Accessibility Insights" (https://accessibilityinsights.io/) - in many cases what this tool (or its older sibling "Inspect" (https://kb.froglogic.com/squish/howto/getting-information-toolkits-gui-controls-windows/#using-inspect-to-get-object-information-via-ui-automation)) identifies can be identified by Squish for Windows as well.