Squish! An Automated GUI Test Tool Now For Eclipse 3.4, Qt 4.4

EddieC 0 356 Views

If you’re looking for low-cost GUI-test automation for Java, Qt, Mac OS X and Web applications, here’s a product you might find useful. Have you heard of Squish? It’s an automated function-testing tool from Froglogic. Released today was Squish 3.4, adding support for the May release of Trolltech’s , the June release of Eclipse 3.4 Ganymede, and for testing applications using varying GUI technologies from within a single test case.

Also new in 3.4 is integration with Apache’s Ant build system and the CruiseControl framework for continuous build and integration process. Qt 4.4 now supports Qt, Java Swing/AWT, Java SWT/Eclipse RCP, Mac OS X Carbon and Cocoa, Tk or XView and HTML/Ajax-based Web applications. For scripting in Squish, take your pick of using JavaScript, Perl, Python or Tcl.

This past March Froglogic released Squish 3.3, which included an improved object map editor, generic script APIs, better synchronization of item-view widgets and the ability to automatically save a screenshot for every test failure. Squish 3.3 also added integration with the Eclipse Test & Performance Tools Platform and support for Mac OS X 10.5 (Leopard) and its native Carbon and Cocoa apps.

Added to the Qt version of Squish 3.3 was support for record and playback of native Win32 controls in Qt apps and improved recording of several widgets. The Java edition got the ability to test apps mixed with AWT/Swing and SWT/RCP. Enhancements to its record and playback capabilities included support for drag operations, Java sub-apps started from within a main Java app and controls based on the Eclipse Graphical Editing Framework. There also were numerous enhancements to record and playback features in the Web edition.

Based in Hamburg, Germany, Froglogic was founded by former software engineers of Trolltech, which earlier this month was acquired by Finnish cell-phone giant Nokia.

Dani AI

Generated

— nice find. A few practical tips for anyone starting with GUI automation that complement an announcement like this.

Start small and design for long‑term maintenance. Keep a compact smoke suite that runs on every build and a larger acceptance suite that runs nightly. Encapsulate UI access behind small "screen objects" so tests read like business actions and locators live in one place. Example (pseudo):

class LoginScreen:
    def username(self): return ui.find("username_field")
    def password(self): return ui.find("password_field")
    def login(self, user, pwd):
        self.username().set_text(user)
        self.password().set_text(pwd)
        ui.click("submit")

Make locators and synchronization robust. Prefer semantic properties (IDs, automation names) over coordinates or fragile image matches. Use condition-based waits rather than fixed sleeps and capture a screenshot plus a UI dump on failure to speed debugging. For applications that mix GUI toolkits, create a thin adapter layer per toolkit so tests use a consistent API even when the underlying widgets differ.

Plan CI and environments carefully. Run GUI tests on dedicated agents or isolated VMs with an active desktop session (use a virtual framebuffer on headless Linux). Treat parallelization cautiously — most GUI tests need one desktop session each, so scale with multiple agents. Archive logs, screenshots, and the UI dump on each failure so failures can be reproduced without rerunning immediately.

Process matters as much as the tool. Use any recorder only to bootstrap tests, then refactor toward maintainable code. Balance UI coverage with unit and service tests so builds are fast and stable. Regularly triage flaky tests: either fix, quarantine, or retire them to keep the suite valuable.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview