FrogBlog

In two days our company froglogic will have it’s 4th anniversary. The past 4 years have been very exciting times for us.

Harri and I started the company in July 2003 (the hottest summer I can remember), after just having relocated to Hamburg. At this time the economy was still rather bad and I remember some pessimistic comments from the lady at the counter when we registered the company.

We started by working out of a small room in Harri’s apartment and our only start-up investment were 2 computers so we could start developing Squish. I coincidently found a design overview document of Squish which I wrote back then, so I thought I could as well post it here as attachment

We continued working in this setting for quite a while and it was good to see that Squish (for Qt only at this time) really started taking off in spring/summer 2004. Beginning of 2005 we felt confident enough that Squish will keep growing, so we finally moved into small offices and hired our first employee in May 2005.

The number of employees, our revenue and profit kept growing organically and we moved into bigger offices around Easter 2006. At this time we also started extending Squish for more technologies, such as Web testing and Java testing.

In a month we will move into new offices yet again since Harri and I had to move into the conference room already due to too little space in our current office.

I’m looking forward to the coming years and further growth. I’d also like to take the chance to thank all our customers, users and partners for their support and trust in us in the name of the froglogic team.Squish DesignSquish Design

Most programmers have a favorite beverage they like and need for programming. For some it is coffee and for others it is some cola brand. I was never one of these: I always preferred tea over coffee (and I know quite a bunch who prefer tea as well).

Here at froglogic’s office, people really like Bionade. I never liked it. But luckily our supplier recently ran out of it and it was not available when Harri was doing his order. So he tried something new: Club-Mate

The correct pronounciation of it seems to be the “German” way, i.e. [ˈklup ˈmaË?tÉ™] and not the English way ['klÊŒb meɪt]. The reason is that Mate has nothing to do with English word for a friend, but with the South American mate tea. And Club-Mate is basically an ice-tea variant made of mate tea.

Well, to make a long story short: I am now addicted to this stuff. The first sip I did was awful, but after finishing the first bottle I reluctantly tried a second one. And after that, I started to really enjoy it. This seems to be quite common: somewhere on the web I read that it is like starting to smoke — nobody enyojed the first cigarette either. (But the good thing of Club-Mate seems to be that it is rather healthy, contrary to cigarettes.)

The good thing is that only Harri and me got around the first sip and nobody else in the office is enjoying it. So we don’t run out of it that often. But just now I am drinking the last bottle, hoping that Harri placed an order for more.

Oh, I just notice that my build finished. So back to work for me. And what is your favorite beverage for programming?

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 »

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

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!

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.

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.

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

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

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 »