Blog

  • 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
  • Using HTML5 data attributes in Squish/Web object names

    By on June 27, 2017

    One of the more challenging aspects of creating Squish tests is the generation of stable object names. The name to identify an object should ideally never match any other object on the screen. And using a name for identifying an object should not include data that is to be used for a verification, since that would disallow doing multiple verifications if one of them fails as an object lookup error aborts the test execution. In modern Web applications it is common to use data attributes to include internal data information for web objects visualizing that data. This internal data can be useful to improve object names that are unstable or that should be isolated from expected changes in the visible text of the object.

    Read more
    froglogic
  • Accessing a SQL database from your JavaScript Test

    By on June 19, 2017

    A common task in GUI tests is to automate entering some data into forms. To properly test and verify such scenarios, it is often necessary to interact with the database backend from the test. As an example, let’s take the evaluation form on our website and assume we’d like to write a test for this. So whenever a visitor fills out the evaluation form, among other things the entered information is put into an SQL database. Let’s assume the following tables in the database backing the evaluation request form. CREATE TABLE evaluation_requests ( id CHAR(36), insertTime timestamp DEFAULT CURRENT_TIMESTAMP, name VARCHAR(255), email VARCHAR(255), company VARCHAR(255), countryCode CHAR(2), productId SMALLINT, PRIMARY KEY (id) ); CREATE TABLE countries ( id CHAR(2), name VARCHAR(255) ); CREATE TABLE products ( id SMALLINT, name VARCHAR(255) ); And let us take the following scenario as the test we want to automate: Feature: Creating Evaluation Requests...

    Read more
    froglogic
  • Squish Tip: Using startSection/endSection to improve test result readability

    By on June 13, 2017

    Sections are especially useful for marking groups of related results in data-driven testing, and also for describing a hierarchy of test results, where simple log messages will simply not suffice.

    Read more
    froglogic
  • Approaches to creating BDD Scenarios

    By on June 6, 2017

    Behavior Driven Development uses conversations around concrete examples of system behavior to get a common understanding of features that are going to be implemented. This is the heart of BDD, as the quality of those examples affects the whole development process. How to organize this conversation in practice? There are three approaches, that I would like to present. The whole team workshop This approach is good for teams new to BDD. At an early stage of iteration gather everyone involved (Bussines Analysts, Developers, Testers) to start a conversation about scenarios that examine a feature to be implemented. As everyone involved gives input and instant feedback, high-quality examples are created as a result of this meeting. Additionally, it gives the team a shared understanding of the features. But it comes at a high cost: such a meeting is hard to organize (people are busy) and expensive (people hours). Three Amigos...

    Read more
    froglogic
  • Squish Tip: Silent verifications

    By on May 30, 2017

    Motivation The verification functions provided by Squish have built-in logging that can be augmented or customized, one of this customizations allows to silence the logging of test.vp() calls. In Squish the synchronization between the test script and the application is mostly done via the use of the waitForObject() functions. This means that your test script waits for a specific condition, such as an object (a popup for example) to exist, before executing further actions. In some cases a synchronization needs to be made based on the result of e.g. an image verification. We would achieve it by polling the results of a test.vp() call, for example: # -*- coding: utf-8 -*- def main(): startApplication("MyApplication") while test.vp("MyTest"): continue #following actions But this has the side-effect of reducing the readability of the test report due to the default logging of each call to test.vp(). Squish provides a setting to silence the logging of any test.vp() call...

    Read more
    froglogic
  • Squish Tip: Customizing QtQuick support

    By on May 23, 2017

    Motivation Squish supports automating QtQuick 2.x based applications out of the box. One frequently asked question is about custom QML components or custom QtQuick controls and how Squish supports these. Testing QtQuick with Squish is very similar to Web testing in this regard. By default, Squish will record on the basic elements that a component is made of. For custom controls this means that Squish will usually record on some BackgroundImage, Text or Rectangle item instead of the expected control. By extending Squish and giving it knowledge of these custom types, we can record test scripts that are easier to understand and maintain.

    Read more
    froglogic
  • Squish Tip: Testing Tooltips on Windows

    By on May 16, 2017

    For many Windows controls (i.e. GUI components) Squish exposes the tooltip property. That property can be checked during a test execution using standard Property Verifications. But how can you check whether the tootlip is really displayed to the end users? You first have to trigger (i.e. display) the tooltip by moving the mouse cursor over a component (see the line 17 in the code below for our Addressboook example), then you can iterate over all top-level objects and check their class names (see the loop at line 3). Native Windows tooltips are of the window class “tooltips_class32” and tooltips from Windows Forms have class names like “WindowsForms10.tooltips_class32.app.0.b7ab7b”. So usually they have the part “tooltips_class32” in common and that can be used to identify top-level tooltip windows. Once you have identified the tooltip window, you can just check its text property (see the line 7). function verifyTooltip(tooltipText) { var topLevels = object.topLevelObjects(); for...

    Read more
    froglogic
  • Squish Coco: MC/DC Coverage and Short Circuit Explained

    By on May 9, 2017

    Modified Condition/Decision Coverage (MC/DC) is a code coverage metric that is referred to in many safety standards as the highest level of quality. It was first defined to provide an intermediate metric between condition and multiple-condition coverage for integrated circuits. Whereas plain condition coverage was considered too simple, the Multiple-Condition Coverage has the drawback of a potential exponential explosion of test cases. MC/DC is a compromise that guarantees a number of test cases that merely grows linearly with the number of conditions, while still achieving a higher level of confidence compared to basic Condition Coverage. Here is the DO-178C standard definition of MC/DC: Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken all possible outcomes at least once, every decision in the program has taken all possible outcomes at least once, and each...

    Read more
    froglogic
Load More