FrogBlog

One of the new features of Squish/Web 3.1 (released last month) is the new XPath support. I’m blogging about that since I notice from support requests that this new feature isn’t known well enough yet by our Squish/Web customers although it solves many problems in a very elegant way.

In Squish you can retrieve a reference to an AUT object (DOM element in the web page in this case) by its name using the findObject function. In Squish/Web you can call on each such object evaluateXPath(). This will evaluate the XPath statement using the object itself as context node. You get back a XPathResult which gives you access to the result nodes or values.

So our object identification using property lists combined with XPath is really powerful. I noticed that also the other day when one of our QA engineers was working on tests for a customer in the scope of a testing kick-start where we create first tests for our customers. Here is such an example:


var item = findObject ("{tagName='TABLE' id='treeTable'}").evaluateXPath("//TR[normalize-space(TD[2])='" + itemText + "' or TD[2]/A='" + itemText + "']").snapshopItem(0);


Doing that without XPath using DOM API (firstChild, nextSibling) would be quite tedious compared to that. It’s of course also possible to do verifications this way:


var result = findObject( "DOCUMENT" ).evaluateXPath( "//*[contains(text(),'not valid with the supplied password')]" );
test.compare (result.snapshotLength, 1);


So I can only encourage Squish/Web users to make use of this new 3.1 feature as it will make life easier.

Next time I will talk about a new feature for synchronization which appeared in 3.1 which will be further improved in the upcoming 3.2.

This blog entry is written from my brand new PC featuring an Intel Core 2 Duo 3800+ CPU, 2GB RAM, 240GB HDD and (drumroll please) Microsoft Vista. As more and more of our customers start using Vista, it became apparent that we need to be able to test Squish and on Microsoft Vista, to see whether recognizing widgets and whatnot still works.

 I didn’t get around to actually trying Squish yet since I’m still aaaahh’ing and ooooohh’ing over all the new fancy effets. I think Rainer (Mac OSX fan) is a bit jealous. I like that!

As I promised in my last post, we I will talk about some new Squish features which we are working on here. Today I’d like to talk about some object name enhancements which will appear in Squish 3.2.

In Squish 3.1 we already introduced multi-property names in Squish as an alternative (now default) object naming scheme (Squish/Web uses this since 3.0 already). Admittingly there were some bugs in Squish 3.1.0′ multi-property name generation for Squish/Qt, but it works quite well in 3.1.1 now.

Such a name may look like

{type=’QPushButton’ label=’OK’ windowCaption=’MySuperApp 2.9′ windowType=’QDialog’}

This will identify the OK button in the dialog with the caption ‘MySuper App 2.9′. Note that this name is quite robust because it will work even if the dialog’s internal hierarchy/structure changes and also it is robust even though no QObject name has been set for the button.

But there is one disadvantage: The caption has a version number. So when you increase your app’s version number you need to do a change in the object map.

One improvement in Squish 3.2 will be that you will be able to do wildcard and regex matching in the name. So you could then do e.g.

windowCaption~=’MySuper App *’

instead. This will certainly help many users out there

But there are two more improvements in the object naming which we will do. One is that a name can refer to another widget directly by a name (real or symbolic). So we won’t have containerName, containerType, widgetLabelLeft, etc. anymore but just container=’name’, etc. This way names will become even better maintainable.

The other improvement will be that it will be possible to configure which properties to use for identification for which object types. This is useful for custom widgets and also if you want to override a default behavior.

So much for today, more coming in the next days…

Since we released our new Squish/Java edition, we got asked a few times if it is possible to test java apples with Squish/Java.

While we don’t support testing applets running in a web browser yet, it is possible to test them through the appletviewer. On Windows, just create a batch file which looks like


c:\java\bin\appletviewer -J%SQUISH_JAVA_DEF_1% -J%SQUISH_JAVA_DEF_2% c:\java\demo\jfc\SwingApplet\SwingApplet.html


Similarly, on Linux create a shell script


#!/bin/sh
/usr/local/jdk/bin/appletviewer -J$SQUISH_JAVA_DEF_1 -J$SQUISH_JAVA_DEF_2 /usr/local/jdk/demo/jfc/SwingApplet/SwingApplet.html


Now set the batch file or script as AUT and start recording!

BTW: SQUISH_JAVA_DEF_1 and SQUISH_JAVA_DEF_2 are set by Squish when starting up the AUT and expand to some options to be passed to the Java runtime.

For future versions of Squish/Java we will add support for testing java applets in the web browser. That combined with Squish/Web will be then really powerful allowing to test the HTML page and java applet in an integrated test.

Well, we will post more about upcoming, exciting Squish 3.2 and Squish 4.0 features in the coming days and weeks. So stay tuned…

The froglogic web log - short FrogBlog - is officially online as of today.

We have been looking for ways to improve communication with our users for quite some time. A blog seemed like a good choice. We are not exactly a large corporation but keeping each of our users informed about we are working on has already become a challenge. Our development process is also very much demand driven so we invite everyone to make suggestions and provide feedback.

This site is running the WordPress blogging software which appeared to be a good candidate after a little bit of searching. It was very easy to set up. Not as fast as suggested by the The Famous 5-Minute Installation guide but almost. Not much customization has been done on the templates and various settings so far but will surely happen over time.

I see that Frerich has already beaten me with a first post reporting about the experiments has done with post-processing Squish’s XML output. I’m sure each of our users will find it to be an interesting read.

One feature of our squishrunner program (which starts and controls the test execution) is that the output of the test can be given in different formats. This can be accomplished by using the ‘–reportgen’ argument and specifying an output format and an output file (i.e. ‘–reportgen xml,/tmp/results.xml’). In particular, the current version lets you generate an Excel table or a XML file with the test results instead of plain text output. The former is a simple way to make your PHB happy, the latter can be used as a hook into a whole new range of test result visualizations. (more…)

This is the blog of employees of froglogic GmbH a software company based in Hamburg, Germany. We are makers of the cross-platform GUI testing tool Squish and offer consulting services related to cross-platform development and quality assurance.

This blog serves as a platform to inform our users and other interested people about the latest news about our products and company, interesting stuff we learnt about plus some irrelevant gossip. Everyone is invited to post comments and provide feedback.

Opinions posted here don’t necessarily reflect the opinion of froglogic GmbH. Neither can the company be held responsible for any material of web sites linked from this one.

Contact details:

froglogic GmbH, Ehrenbergstr. 69, 22767 Hamburg, Germany
Phone: +49 40 78897137
E-Mail: contact@froglogic.com

Managing directors: Harri Porten, Reginald Stadlbauer
Registered office: Hamburg
Trade Register Number, City: HRB 92585, Hamburg