FrogBlog

Now that Squish is adopted more and more in large enterprises (Siemens, Reuters, etc.) we often get asked for references.

We were able to make another reference public by interviewing Ericsson, who started to use Squish for the Java GUI testing last year.

You can read the interview here.

The JavaOne conference taking place next week will be our 3rd event to exhibit at this year. All of our customers and interested parties are invited to visit us at booth #940 in the Pavilion. We’ll be doing live Squish presentations and follow our tradition to hand out green gummi frogs. The conference program is loaded with interesting topics but I bet - and hope - that we’ll be too busy to attend any session ourselves.

We’ll be switching planes at London Heathrow on our way to San Francisco and back. When booking the flights I was still looking forward to using the new Terminal 5 to escape the traveller’s hell that Heathrow can be. Little did I know about the chaos that would arose at the day of its opening. Hope it will have settled once we are arriving there.

Anyone in for a spontaneous conference visit: please get in touch with us as we can provide reduced and free passes for the conference and exhibition area, respectively.

I will today abuse this blog to publish some work without having to write documentation for it.

While demonstrating Squish in web demos and at conferences I often get asked about keyword driven testing. Due to the powerful scripting features of Squish, this is quite easy to do with Squish. Now that I created such an example for a customer demo later this week, I thought I’d publish the perpared test so you can have a look at how simple it is to do a keyword driven test in Squish.

You can download the test suite from http://www.froglogic.com/~reggie/suite_nomadpim.zip. It contains three tests and some shared script files.

The first test case is the test script with hardcoded data but already abstracted into several functions (which will later serve as keywords).

The second test cases is the same but in a data driven fashion by using an external data file.

The third test shows how to turn that into a keyword driven test where the test steps and data comes from a data table and the script (keyword_driver.js) is completely generic.

So far there is not much documentation available for that but the tests and shared scripts are quite self explainatory.

Maybe we get around to create a nice tutorial out of that for Squish 3.4.

BTW: The test is for a standard Java RCP application which you can download from nomadpim.sourceforge.net

A common problem when developing test scripts for Qt application is that some table should be checked for whether it contains the correct data. In particular, the expected data is stored in an external file and the test script should load the file and then compare its contents against the table cells. Here’s one way to do it, in Python:

def checkTableAgainstTestdata( tableName, testDataFileName ):
    table = findObject( tableName )
    dataset = testData.dataset( testDataFileName )  

    columns = table.columnCount
    rows = table.rowCount  

    testDataColumns = len( testData.fieldNames( dataset[ 0 ] ) )
    if columns != testDataColumns:
        test.fail( "Tables does not match test data",
                   "Table " + tableName + " has different number"
                   " of columns than test data in " + testDataFileName )  

    row = 0
    for idx in dataset:
        for col in range( 0, columns ):
            if col >= testDataColumns:
                break
            expectedText = testData.field( idx, col )
            tableText = table.item( row, col ).text()
            test.compare( expectedText, tableText )
        row += 1  

        if row >= rows:
            test.fail( "Tables does not match test data",
                       "Table " + tableName + " has different number"
                       " of rows than test data in " + testDataFileName )
            return  

    if row >= rows:
        test.fail( "Tables does not match test data",
                   "Table " + tableName + " has different number of"
                   " rows than test data in " + testDataFileName )
        return

The function simple takes the name of the table object to check as well as the name of the test data file. The test data file is expected to live in either the test cases “testdata” directory or in the shared testdata directory. A sample invocation might look like:

def main():
    tableName = "{type='QTableWidget' visible='1'}"
    testDataFileName = "expectedvalues.tsv"
    checkTableAgainstTestdata( tableName, testDataFileName )

Note that this doesn’t work for Qt3 QTable objects or with plain QTableView objects. For those, the API for aquiring the contents of a specific table cell is different. However, the algorithm of the function is the same.

Hi!

You can read an interview with one of our Squish for Java users on our web site.

It talkes about their test automation process and why they chose Squish over Mercury’s (now it’s actually HP) Quick Test Pro.

Important: The following information applies for Squish for Qt only.

Squish allows you to do remote testing with the squishrunner running on one host and squishserver (that starts your AUT) on another host. The script interpreter is living in the squishrunner process. So all script commands are executed on the first host and not on the second host that is running your AUT. Only Qt objects (and function you execute on them) are forwarded to the second host and are executed there.

So if you create e.g. a Python file object in your test script, you can only access the file system of the first host. But if you create a QFile object, you can actually access the file system of the second host. But for this to work, the AUT has to be running. And you need some knowledge of the Qt API.

In froglogic we use a dummy application that provides simple shell-like features that are actually executed on the remote host. So if you need such a functionality, read on to find out how to use this in your own test setting.

(more…)

Squish for Qt is available as a binary package and a source package. The binary package is available for common platforms and compilers, but sometimes the Qt version you need is missing. Or maybe it is there, but it was built with a Qt configuration that does not match the Qt version you use in your project. In all these cases, you have to use the source package and build Squish yourself.

This might be hassle since you need to install the wanted scripting languages, e.g. This becomes even more of a problem if you want to build Squish on one machine and use the one build on many other machines (because the scripting languages have to be installed on that machine as well).

The advantage of the Squish binary package in this respect is that all is already packaged.

It becomes even worse if you are in the unlucky situation that you have to do a split build of Squish because your applications Qt version is that old that some parts of Squish does not support it (e.g. testing Qt 3.0 applications) or if your application is using a single-threaded Qt library.

So wouldn’t it be nice if you could just use the ease of installation of the binary package together with the flexibility of the source package? Well, you almost can.

(more…)

Squish has support for testdata: you can specify a tab (or comma) separated list of data, store it in an external file and iterate over each line of it with its scripting API (and access the fields of each line). Squish also has a builtin editor to edit such testdata.

So with Squish it is easy to have testdata you can store in a table. However, when I write a test I have the need to have more complex testdata; testdata that can’t be easily represented in a table (e.g. data where one field would be a list again). Am I lost? No.

(more…)

Testing with the Squish Qt edition, one can add (from the Squish documentation)
var num = QInputDialog.getInteger( "Require User Input", "How many pages have been printed?" );
in the scripts. So testers can fill-in data that the program can’t see.
Unfortunately testing with the Java edition and using the SWT toolkit, there is no such a ready-to-use dialog for this.

However, the Java edition of Squish is easily extended because classes are dynamically wrapped at application startup. We must therefor write an input dialog ourselves, tell Squish about it and call it from our test scripts.

So first write a simple input dialog

package com.froglogic;
import org.eclipse.swt.widgets.*;

public class Input
{
public static String getMessage( Shell parent, String question ) {
...
}
}

The implementation is in the input.zip file, together with a jar file containing the compiled classes of the sources.

Now we must add the .jar to our classpath. (Btw. Squish 3.2.1 will now finally have an editbox for setting the classpath and main class in the testsuite settings dialog.)

Next we must tell Squish that we want to wrap the new classes. So we must carry out the task “Wrapping custom Java™ classes” from the Squish User Guide.
Basically write a .ini file, like:

[general]
AutClasses="com.froglogic.Input"

and register this by squishserver:

squishserver --config setConfig MyAUT /path/extras.ini

Finally use the code in our scripts. I’ve put it here just after the script is waiting for a CCombo widget:

var shell = findObject(":Buttons_org.eclipse.swt.custom.CCombo").shell;
test.log(com_froglogic_Input.getMessage(shell, "What's your name?"));

In the code above the return value is directly printed in the test results.
Note that the property CCombo.shell is a synthetic property, I’ve could have used CCombo.getShell() as well.

Summarizing, it requires some work but it is not very hard and without modifying any code of the application we’re testing.

Today’s the third, and last, day of our stay at the Webinale Conference. Squish is still a rather new and unknown contender in the AJAX world but it turned out that this is not a disadvantage. In fact, the whole scene is moving so quickly that there’s always something new (sometimes useless and over-hyped, sometimes interesting) and something else is outdated.

One nice thing about this conference is that even though there are a few vendors of AJAX Toolkits here, and lots of talks about how to write proper web applications, nobody cares about testing those GUIs yet. We’re the only ones to tackle that topic and hence get a very good amount of attention here by the visitors. Reggie’s talk was also received very well and even though the conference is rather smallish (this is the first year it’s taking place), we managed to get hold of a good number of leads (which, by the way, are of rather high quality - most people here already thought about testing, tried other testing solutions, and are generally everything but new to the topic).
(more…)