Complex Testdata in Squish

June 25th, 2007 by Rainer Schmid

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.

Read the rest of this entry »

Extending the script bindings for Java

June 12th, 2007 by koos

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.

Webinale

May 23rd, 2007 by Frerich Raabe

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).
Read the rest of this entry »

Webinale 07

May 21st, 2007 by Reginald Stadlbauer

In about 3 hours, Frerich and I will fly to Stuttgart for the Webinale 07 conference - a two-day German Ajax/Web 2.0 conference and exhibition.

We will man a booth there to show off Squish 3.2 (specifically the Web edition). Tomorrow (May 22nd) at 10:30 I will give a talk on automated Web/Ajax testing where I will talk about the experience we gained on this topic and what to look out for when automating Web tests.

So if you are at the Webinale, make sure to drop by our booth at least for an infameous gummy frog!

Dealing with dynamic object names

May 15th, 2007 by Reginald Stadlbauer

Now that Squish 3.2 is out I want to write about a scenario where you can take advantage of new Squish 3.2 features.

One common problem, esp. when testing web applications, is to identify objects with dynamic parts (such as IDs) in their object names. Usually these properties have a dynamic part, such as a unique number, in it which we want to ignore in the object name.

With Squish 3.2, this is now easily solvable.

Squish is extensible so you can extend the name generation method for such objects. Details can be found at http://www.froglogic.com/download/book32/book/ug-jsapi.html. Additionally, Squish 3.2 supports regular expressions and wild-cards in object names. With a combination of those two features, the problem can be easily solved.

So let’s assume we have DIV elements in our web application representing widgets which we want to access from our test scripts. These DIVs have ID properties, which we can use for the identification. But the IDs contain values like id=’fileOpen_2376327′ where the section after the underscore is dynamic and should be masked out when identifying such an object because it will be different on every run of the application. So we want to identify the object using id?=’fileOpen_*’ in the real name (the =? tells Squish that we want to do a wild-card match instead of a strict match).

But we don’t want to manually change every entry in the object map after recording a test. Squish should automatically generate such names when we record an interaction on such an object.

To allow this, Squish now comes with an extension API. So we create a JavaScript extension file with the following code


function myNameOf(o)
{
if (o.tagName == "DIV" && o.id) {
var id = o.id;
var start = id.indexOf('_');
if (start == -1) // generate default name when we don't find an underscore
return undefined;
id = id.substr(0, start) + "*";
var n = '{' + Squish.propertiesToName(o, ["tagName", "className"]) + " id?='" + id + "'}";
return escape(Squish.unifyName(n, o));
}
return undefined;
}


// install our name hook
Squish.addNameOfHook(myNameOf);

What this code does is to generate a name with the wild-card ID for our DIV elements. The API which can be used in such Squish extensions is documented in http://www.froglogic.com/download/book32/book/ug-jsapi.html.

Now we need to register that extension file by opening the file squish.ini, which you we find in the ‘etc’ directory of your Squish directory. There we add an entry


Wrappers/Web/ExtensionScripts="[path]/[myextension].js"

If we now record a test and access a DIV element with such a dynamic ID, a wild-card name will be generated automatically.

The example here is quite simplistic but shows the concept of such an extension. Much more can be done with the extension API. So refer to the documentation referenced above for more details or write a comment here!

Similar extensions and customizations are also possible in all other Squish editions.

Revision Control with SVN

May 11th, 2007 by Frerich Raabe

Today we finally switched to Subversion as our revision control system at work. After using CVS for about ten years, the list of things we didn’t like about it became long enough to justify switching to something different.

At first it wasn’t quite clear what that “something different” would be; many KDE people (mainly from the Linux camp) suggested to use Git but that’s a no-go for us (we need our revision control system to work on Windows as well), leaving aside that some people here would probably rather walk over broken glass than adjusting their work style. :-)

Since we’ve been using Subversion for quite some time at KDE, and we know that it feels very much like CVS (minus the annoying things), it came as a natural choice. First attempts to convert our internal repository went very well, and now - with the switch being final - many scripts which were developed as little side projects to KDE, such as ’svnlastchange’, become useful to us, too.

And I don’t have to do the mental switch between svn and cvs all the time when moving between the office and home. :-)

The biggest advantage Subversion gave me so far is related to merging patches: I have different checkouts for different Squish branches (one for 3.2, one for HEAD^H^H^H^Htrunk, et cetera) and very often I’m committing something to one checkout and then want to merge the same patch to the other checkout. I wrote a little script for that called ‘ilc’ (for ‘integratelastchange’ ;-)) which makes that very easy. With that script I can just do


$ cd ~/src/squish/trunk
// .. Hack away ..
$ svn ci foo
Sending foo
Transmitting file data .
Committed revision 12000.
$ ilc 12000 ../32-branch

And that’s it. However, I’d like to get rid of the revision number argument so that when the script is invoked with just one argument, it will always integrate the revision which I just checked in. Unfortunately the different types of revisions (COMMITTED and BASE and PREV and whatnot) confuse me a bit, I couldn’t find the right one yet.

Maybe some reader knows how to do that?

Even if that can’t be solved, I can now hardly imagine how we managed to survive this long with CVS on KDE. :-)

New offices

May 8th, 2007 by Reginald Stadlbauer

With our latest addition to our team (say hi to Rob!) we reached the space-limit of our current office. Actually considering that Harri and me are sitting together in the meeting/lunch room I’d rather say that we grew out of it already. At least nobody can waste time in meetings this way :-P

So we looked for new offices and recently signed the contract. For the locals, it is in the “alten Gaswerk” which is a really nice area with a beautiful atmosphere. It’s a new building with no interior yet. So the land-lord is setting set up the offices, walls, floor, etc. according to our needs which is really nice.

We will move there later this summer so everybody will have enough space again. Let’s just hope we will stay there for more than a year this time :-)

KDE’s Panel Vacuum

April 27th, 2007 by Frerich Raabe

I’m quite amazed by how technologies which I used to discard as ‘hype’ (like, Solid or Phonon or so) actually seem to work. For real. Maybe I should feel a bit of shame but I don’t since this reflex of being sceptical of projects which have a fancy code name but not visible code base has proven quite useful in the past - helps to avoid working on vapourware.

Anyway, one of the KDE features of which I didn’t see anything other than mockups yet is KDE’s new panel framework thing dubbed Plasma. I was aware of the fancy web page for some time now (now that I view that page again - what the heck is ‘Appeal’? appeal.kde.org redirects to www.kde.org - is that an omen already?) but still, I didn’t actually *see* it yet. Of course, it’s listed as some integral part of the KDE4 architecture, but that’s pretty much all the information I could get out of KDE’s tech base regarding Plasma.

Okay, not quite. There’s the Plasma project page in the techbase. Unfortunately I can’t claim that it made things any less shady for me. Call me a pessimist but I don’t think that it’s a good sign the Raport Menu Plasmoid has a fancy logo but no code. Maybe I’m lacking vision or professionalism but I prefer to have something before I give it a logo or a name. And something means something which I can compile and run and fix.

Well, I’m not trying to be a naysayer here but I think that the situation around Plasma is kind of… shady. My impression is that it’s –> <– this close to dieing the dreaded buzzword hype death. On the other hand, this is maybe not such a bad thing… Read the rest of this entry »

Hello from the JAX 07

April 25th, 2007 by Reginald Stadlbauer

We are currently exhibiting at the JAX 07, the largest Germany Java conference and expo. It is certainly the largest expo we have been to and also the conference with the longest opening hours (8:30am - 9:30pm) :-P

The traffic at the booths is average compared to other shows we have been to. It’s is good to be here since we aren’t very known in the Java world yet so this is a good opportunity to get known and show the products we have. The feedback we get is very positive as there is a lot of demand for automated GUI testing which goes beyond the generic tools which are available.

Tomorrow I will have my talk about automated Java GUI testing.

Here is also a picture of our booth.jax11.jpgjax11.jpgjax11.jpgjax11.jpgjax1.jpg

Always Show a Tooltip with Carbon or Cocoa

April 23rd, 2007 by Rainer Schmid

I had the following problem on the Mac: in certain circumstances I want to always display a tooltip and change the text of the tooltip as the mouse moves over different objects. So I looked around and I found the Carbon Help Manager Reference.

The functions HMDisplayTag() and HMHideTag() seemed to be exactly what I was looking for. Implementing this was rather straightforward and it worked most of the time. But sometimes it simply stopped working; after some debugging I found out that after the call of HMHideTag(), I did not get any mouse moved events anymore.

So I looked around for other solutions and found the tooltip article on CocoaDev. That one looked really promising. It has two different approaches of implementing your own tooltips with Cocoa. But since they simply display a window with a style that resembles tooltips, I continued looking (after all, if I use Apple’s tooltip API, I am more likely to get a correct look of the tooltips, especially if Apple decides to change the look of tooltips at some point).

But on CocoaDev there is also an article that shows a different approach: it uses the Cocoa NSHelpManager class to do this job.

This code simply uses the showContextHelpForObject:locationHint: function to show the tooltip and the removeContextHelpForObject: to hide the tooltip. Happy to have a found another solution, I tried this and showing the tooltip worked just find. But to my disappointment, I was not able to get rid of the tooltip anymore — the removeContextHelpForObject: did in fact not hide it. I tried several different ways, but with no luck.

So to cut a long story short, I ended up with using HMDisplayTag() again to show the tooltip. And since the HMHideTag() call was the only thing that caused me trouble, I simply replaced it with:

    WindowRef helpTagWindow = GetFrontWindowOfClass(kHelpWindowClass, true);
    if (helpTagWindow)
        HideWindow(helpTagWindow);

As far as I can tell, this works just fine for me. So I will stick to this unless I discover any mayor problems.