Archive for May, 2007

Webinale

Wednesday, May 23rd, 2007

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…)

Webinale 07

Monday, May 21st, 2007

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

Tuesday, May 15th, 2007

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

Friday, May 11th, 2007

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

Tuesday, May 8th, 2007

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 :-)