FrogBlog

Hi!

For those of you who use Squish for Web for testing Backbase applications here is a function which you might find useful. It can be used to synchronize on Backbase (BPC’s) loading state. Every time Backbase is loading, this little “loading…” box is displayed. So what the function does is to first wait until the loading box appears and then until it disappears again:


function isBackbaseLoading()
{
clearObjectCache();
var div = findObject("{tagName='DIV' id='loading'}");
if (isNull(div)) {
return false;
}
if (div.property("style.display") == "" || div.property("style.display") == "none") {
return false;
}
return true;
}


function synchBackbase()
{
var ok = waitFor("isBackbaseLoading()", 10000);
if (!ok)
return;
waitFor("! isBackbaseLoading()");
}


So whenever your test triggers an action after which Backbase is loading and you want the test to wait until loading finished, just call synchBackbase().

Latest in Squish 3.2 we will add a built-in function for that, but this example also shows how easy it is to implement that directly in a test script.

Next week we will be in NYC at the AjaxWorld Expo. We finally have all the marketing material put together and printed. So we are ready to go

It will be the largest show we ever have been to as exhibitor, so it will be exciting. As you can read in our blog posts, we have many new and cool features coming up in Squish 3.2 and 4.0 and it will be great to show-off some of this already.

Besides exhibiting I will also give a talk on automated testing of AJAX applications.

Being at AjaxWorld will also be a great opportunity to finally meet many of the AJAX toolkit vendors in person which we are in contact with constantly. So expect some news about new cooperations regarding better integrations of Squish for Web with the popular AJAX toolkits.

So if you happen to be there as well, make sure to drop by our booth to say hi.

I have been interviewed by Conference Guru up-front to the AjaxWorld Expo next week where I’ll give a talk about automated Web/AJAX testing. Read more at http://conferenceguru.typepad.com/conferenceguru/2007/03/5_minutes_with_.html

Squish has been using a set of property->value tuples for a while now to identify an object. For instance, to name an object of type ‘Label’ with the text ‘Hello World’, you might have something like:

{type='Label' text='Hello World'}

One inherent problem with this is that it’s hard to decide on the set of properties to use for identifying an object. In particular you want object names to be

• Unambiguous; there mustn’t be more than one object in the
  application which matches the given set of property->value pairs.
• Minimal; you don’t want to have more properties in your object name than necessary, so that you maximize the robustness.

It’s very hard for Squish to fulfill both requirements, since Squish has no knowledge of how your application is built: which properties can be used to identify an object, and which shouldn’t (because they are likely to change, for instance).

Fortunately, with Squish 3.2, you will be able to change this. For each Squish edition, there will be a corresponding XML file which describes which properties shall be used for generating the real (the ‘{..}’) name and the symbolic name (the one starting with ‘:’) for a given type. Squish will come with a default configuration of course, but if you know that e.g. using the ‘id=’ attribute in object names for your Web application isn’t a good idea because those id’s have rather volatile values, then you can edit the corresponding XML file and tell Squish not to use the ‘id’ attribute.

I’m currently implementing this for all our editions, and I’m sure it’s going to be very useful for many of our customers (and for ourselves, too: we are able to throw away a lot of code which becomes obsolete with this system!).

Together with our partner Trolltech we will conduct a webcast where we will show how to use Squish to create and run automated tests on Qt applications. This is a real live webcast where you will be able to ask questions, etc.

Also we will run a special license price offer for webcast attendees.

So if you are considering to use Squish for Qt register now and take advantage of this opportunity: http://www.trolltech.com/campaign/squishwebcasts

One improvement in Squish for Web 3.2 is the Spy object picker and screenshot comparisons. One issue common to both features is to find out the absolute (to the screen) position and size of a given DOM element. This is necessary to draw a highlighting rectangle around the element (for the object picker) and to take a screenshot of a specific element.

Of course there is no cross-browser way to do this calculation. That’s why in Squish/Web versions prior to 3.1 the object picker used a bad hack to highlight elements (changing its background color) and screenshots could only be taken from the whole browser window.

For Squish for Web 3.2 we finally implemented the necessary function to calculate the DOM element’s coordinates. But it really was a pain. There is no API which you can reliably use. It works differently in all browsers (I wasn’t too surprised by that). But also the used DOM APIs returned behaved differently in Firefox depending on the platform.

So our getElementRect() function really does a lot of checking and magic but finally it works for all browsers. So in Squish 3.2 the object picker will be much more useful (since we also display the name of the object when you hover over it now, as we always did in other Squish editions already) and screenshots can be used now for real.

I’d just wish that the browsers wouldn’t be so different. But I guess many share my pain with this

As Reginald previously mentioned Squish 3.2 is going to have an even more sophisticated technique for identifying objects based on some properties. This is achieved by allowing to determine whether a given object matches a given property value not only through a plain string comparison but by also testing whether the object matches a certain regular expression or wildcard-enhanced string.

I just finished implementing a first version of the same powerful magic for Web tests and so far (keeping fingers crossed) it seems to work well without introducing any regressions. Using regular expressions and/or wildcards when patching property values is especially useful for Web tests, since many Web applications happen to encode some more or less random session ID into important attributes. (more…)

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…