Blog

  • Squish Tip: Synchronization with waitUntilObjectReady()

    By on November 14, 2017

    waitUntilObjectReady() is a callback function that by default, does nothing, but it can be defined in your test scripts to do anything you want. The method is called just before waitForObject() returns, and gets as an argument, the object that Squish thinks is now ready to get events. It can be used for synchronizing your tests with objects that may not quite be “ready” immediately after the waitForObject() function returns. This situation can arise when the AUT has extra pending events to process, or extra graphical operations to perform, and this extra processing possibly interferes with the responsiveness of the AUT’s event loop. The simplest use case is to add a delay after each waitForObject(). For example: def waitUntilObjectReady(obj): snooze(.5) In this case, we have added a half-second delay regardless of which object was ready. When you want to watch closely what is happening during playback, this can help...

    Read more
    froglogic
  • Debug Qt application while running Squish GUI tests

    By on November 10, 2017

    Some issues with Application Under Tests (AUT) appear only when a test is executed with Squish. For some cases, it’s easier run our test scenario with Squish than repeating it manually. To get a detailed information about the state of our AUT during a test execution, you can attach to it with an external debugger (gdb/lldb). How to do it? Put a breakpoint after startApplication/attachToApplication in the Squish IDE. Start a Test Case in the Squish IDE and wait until a breakpoint is reached. Attach gdb/lldb to the running process (gdb has an “attach PID” command or -p parameter during startup). Set a breakpoint in the debugger (break command) and resume (continue command) OR display a backtrace (bt command) Resume execution of a Test Case in Squish IDE. Another approach can be used when debugging AUT crashes. For that, we don’t need to attach to running application process. All...

    Read more
    froglogic
  • Tip: Setting up Squish to attach to running applications in a distributed environment

    By on November 2, 2017

    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 can also be used to help Squish attach to an already running application. 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...

    Read more
    froglogic
  • Synchronized batch execution of Squish

    By on October 24, 2017

    Squish test execution involves multiple processes which may even run on different machines. Ensuring that all parts are up and running before actual test execution can be challenging sometimes. The following shows a little trick how automated setups can wait for a local or remote squishserver to become available to avoid execution failures if the squishserver host is slow to respond.

    Read more
    froglogic
  • Coco Tip: Manual testing on a remote system with Coco

    By on October 17, 2017

    In many cases the application to test is not physically located on the tester’s desktop, which requires that the generated application data, such as code coverage information, gets transferred from the target to a host system. This can be realized in different ways: By a manual transfer through a physical storage medium (USB stick, HDD, …), which is not convenient, By mounting a shared network drive from the target and the host system using it as location for all generated files, By a dedicated transfer mechanism. In general, the most convenient way is to use a shared network drive on which the target system generates the coverage information, which then can be analyzed directly on the host system. This is not always possible on embedded systems or due to security requirements. (Most of the remote file systems are not secure enough for using them over the internet. In this...

    Read more
    froglogic
  • Using command line tools for image comparisons

    By on October 10, 2017

    Introduction Squish supports several image comparison methods: pixel strict, pixel fuzzy, histogram and correlation comparison. All of them are used in so called image verification points (Screenshot Verification Point dialog). You can create these verifications during test recording and later on modify them in the Squish IDE. For lots of cases that is usually enough but sometimes you might need a bit more. For example, when you would like to check some images which are dynamically created or maybe when you don’t have the images in advance. In that case you can use the following command line tools: simplecompare, nchcompare and correlationcompare. You can find these tools in the folder ‘bin’ of each Squish installation. Example With a little bit of scripting you can easily use (call) these tools in your test scripts as well: import os import subprocess def simplecompare(image1, image2, threshold=0, tolerance=0): args = , "bin", "simplecompare"),...

    Read more
    froglogic
  • Parallel execution in Squish

    By on October 2, 2017

    With the help of virtual machines one can perform parallel executions in Squish as a time saving strategy. As an application grows, it’s features increase and so do the number of testcases in the corresponding testuite. A testsuite containing a large number of testcases becomes a problem. It takes a long time to finish. The reason for this being that the testcases are run consecutively and a long running testcase then blocks other testcases, which cannot run until the slow testcase is finished. A fast running testsuite is desirable.  If a testsuite takes a long time to finish, it takes a long time before one can analyse the test results. Sometimes all testcases in a testsuite are not run to avoid production delays. This can lead to bugs not being fixed immediately. Mainly because it may take days before a critical bug is even discovered.  Additionally, the person responsible...

    Read more
    froglogic
  • BDD Steps with Parameters

    By on September 26, 2017

    Motivation In Behavior Driven Development, it is possible that individual steps will “reappear” throughout different scenarios or features. Those steps might not be fully identical, but differ only slightly in details, such as a value to fill into a form field. Maintaining two or even more independent step implementations with a lot of duplicate code causes more work in the long run. Over time, changes would have to be done consistently to all copies. Or even worse, some copies are forgotten. Passing parameters from steps to script functions makes it easy to do basic functional decomposition and refactoring on your tests, eliminating duplicated code. Let’s take the following two scenarios as an example: Scenario: Error message when using non-existing credentials Given an opened web browser When the Download Area login page is loaded And I login as 'max' with password 'secret' Then an error message should be shown Scenario:...

    Read more
    froglogic
  • Automating alternate menus with Squish for Mac

    By on September 19, 2017

    The menus on macOS allow for a menu item to have an alternate version: if you press the “Option” key with an open menu, you see the alternate versions and can select them. For example the Squish addressbook example app has a menu item “Bring All to Front” in the “Window” menu. And if you press the “Option” key, then this changes to “Arrange in Front”. Automating the activation of the “Arrange in Front” menu item is possible, but there is one small gotcha: when you record the activation of this menu by clicking the “Window” menu, pressing the “Option” key and then clicking on the “Arrange in Front” menu item, you end up with the following script: # -*- coding: utf-8 -*- def main(): startApplication("SquishAddressBook") waitForObject(":Window_NSMenuItem") activateItem(":Window_NSMenuItem") waitForObject(":Arrange in Front_NSMenuItem") activateItem(":Arrange in Front_NSMenuItem") If you play back this script, it fails with the error LookupError: Object ':Arrange in...

    Read more
    froglogic
  • Overview of the new file comparison functions in Squish 6.3

    By on September 12, 2017

    With Squish 6.3 we added two new file comparison functions. The objective is to make it easier to verify not just the application state but also the output an application might generate. Squish now offers a general comparison function test.compareTextFiles. This function can be used to compare any type of file, but it is very strict. Another function that was added in Squish 6.3 is test.compareXMLFiles. Since XML is a very widely used format, Squish now offers a lot of different comparison options for these type of files. You can use both functions to compare a reference file to the file actually generated by your application. In this article I want to give some examples on how to use the new functions and highlight some of the comparison options. General file comparisons You can use test.compareTextFiles to verify the data stored by your application. Your application might for example...

    Read more
    froglogic
  • Enabling Squish to hook into Sub-Processes started by the AUT

    By on September 5, 2017

    Often more complex application do not consist of just a single executable. Instead the main application launches sub-processes which also open a user interface. Squish is designed in a way to also hook into sub-processes started by the main application under test (AUT). But depending on the platform and the toolkit on which the AUT is based, hooking into sub-processes either works out of the box or needs some small adjustments. This article gives an overview of adjustments that need to be done, if any, or when sub-process hooking works automatically. Hooking into Sub-Processes in Squish for Qt: On Windows: In squish for Qt on Windows there are two ways to enable Squish to hook into the sub-processes started by the AUT: 1. One solution is to make some small changes to the AUT’s source code. This means running a wrapper program (dllpreload.exe, shipped with Squish), that actually starts...

    Read more
    froglogic
  • Benefiting from combined usage of Squish and Coco

    By on August 29, 2017

    It is sometimes a good idea to use Squish GUI Tester and Coco in the same project. Squish runs the GUI tests, and Coco measures how much code they cover. A problem that often occurs is however that the instrumented AUT does not write any coverage results.

    Read more
    froglogic
  • Debugging Test Failures Using Your Favorite IDE

    By on August 22, 2017

    One goal of automated testing through Squish is to find bugs and regressions in your application. The cause for some test failures is easy to spot, other ones can be hard to debug. Squish already provides crash dumps when the AUT decides to give up, but in not-so-obvious cases you might want to take a look with a debugger. One way to do that is to attach the debugger to the running application process. When debugging an issue it can however be more convenient to run your application in debug mode right from your IDE. This way you can experiment with it using Squish while observing behavior from the inside. As you might know, Squish is able to attach to applications that are already running instead of starting them as part of the test script. The feature is useful to test AUTs running on embedded devices for example, but...

    Read more
    froglogic
  • Squish Expert Tip: Java object mapping in Squish for Android (vs. Squish for Java)

    By on August 15, 2017

    The Squish for Java edition wraps all seen Java objects for access in test script with a type which name is the fully qualified Java name, dots being replaced by underscores. E.g. a java.lang.String Java object is wrapped as object with type java_lang_String. On such a wrapped Java object, public methods can be called and access to public fields and objects can be created in Squish test scripts. E.g. the waitforObject Squish script API function returns such a wrapped Java object. An example of a java.lang.String creation with a string “hello” in JavaScript, which then is converted to uppercase and added to the test result, is var obj = new java_lang_String("hello"); var upper = obj.toUpperCase(); test.log(upper); Note that for each of the script languages Squish offers, creating an object instance looks a bit different. For Squish’s other script languages, please see here how to create new Java objects. Java object mapping...

    Read more
    froglogic
  • How to log exact mouse click positions within screenshot results

    By on August 10, 2017

    With screenshot verifications, a failed test run shows us the differences between the expected vs actual images, but in some cases, the actual image is missing, or is missing important information. .  

    Read more
    froglogic
  • Testing Qt Application Manager applications with Squish.

    By on August 3, 2017

    Qt Application Manager (or appman) is a Qt module targeted for embedded devices. It allows you to create rich, Qt Quick-based user interfaces. The module exports an API that allows the Qt Quick GUI to act as a compositing display manager. It supports installing, removing, and life-cycle management of applications. Testing applications written for appman is challenging for a number of reasons. Appman uses Wayland for desktop compositing. Some compositor setups do not support the full set of features yet, such as those needed for the Squish widget highlighter. The upcoming Squish 6.3 release contains a number of Wayland support improvements to deal with these limitations. Testing the Applications Since applications written for the Qt Application Manager are tightly coupled to it, the entire appman should be registered as the AUT, and the “Hook into sub-processes launched by the application” option in the “Test Suite Settings” page should be...

    Read more
    froglogic
  • Global initialization and cleanup functions

    By on July 25, 2017

    Squish offers a great way to separate the main body of your test case, initialization and cleanup parts. It can be useful in many cases, simplifies complexity and improves test case readability. In combination with some scripting it can reduce one of the worst enemies of maintainability – code duplication. The init() and cleanup() functions have a huge advantage over standard functions calls. They are independent of the main() function so even if the code inside the main() throws an error, those two functions are executed. For more information about the init() and cleanup() please refer to our documentation. init() and cleanup() for a single test suite Putting some code into init() and cleanup() functions is often a first step to increase readability and maintainability of your test case. If the body of those functions is the same across different test case it might be a good idea to...

    Read more
    froglogic
  • Finding & Fixing Dependencies Between Test Cases

    By on July 18, 2017

    Works for me! Did you ever hear yourself uttering those words, or maybe you heard them from a colleague? Tests which work on one system may fail on another. This can happen for many reasons: the application under test (AUT) depends on the operating system on which it is executed. The test case code depends on the application build being tested. Or test cases depend on each other, and the order in which they are executed is important. The last issue can become a real problem: as test suites grow, it can happen that implicit dependencies are established between test cases. In this article, we’ll discuss where dependencies between test cases come from, why they are bad, and how to detect them using froglogic Squish.

    Read more
    froglogic
  • Squish GUI Testing Case Study: Topcon Agriculture Group replaces manual testing with Squish Automated Tests

    By on July 12, 2017

    Topcon Agriculture Group makes a line of Console Displays, GPS systems running embedded Linux and software written in Qt. For 5 years, Topcon has been using froglogic Squish to develop and run almost 1000 automated tests against these devices saving their field testers a lot of time: “Within the first year , we developed enough automated tests to save our field testing guys 8 hours per build!” Read the complete Topcon Case Study.

    Read more
    froglogic
  • Keyboard shortcuts in the Squish IDE

    By on July 4, 2017

    Keyboard shortcuts Since the Squish IDE is based on Eclipse it has a lot in common with it, for example the keyboard shortcuts functionality. For me keyboard shortcuts are very important, because they are a way to… boost my productivity (perceived as well as actual – at least I like to believe so), improve how much “at home” I feel with a tool, and avoid – to me – clumsy, “slow” mouse usage (locate mouse pointer, locate target, move to target, aim, click). Viewing & changing keyboard shortcuts In the Squish IDE the existing (default) keyboard shortcuts can be viewed and changed at Edit > Preferences > General > Keys:   Filtering the commands list As the above screenshot shows, there is a long list of commands which keyboard shortcuts are and can be assigned to. To quickly see only the keyboard shortcuts that relate closely to Squish one...

    Read more
    froglogic
Load More