FrogBlog

Best code is written with bad weather outside. This was proven by Maks recent work on KDE’s JavaScript engine at least. While cold and snow were plaguing North America Maks developed some nice and effective optimizations that were merged into trunk last night.

Now what was this about? The easy but slow dynamic variable lookup of KDE 3 is now replaced by a static lookup where the symbol can be bound to a local variable. On the other hand, local variables are skipped if a variable is known not to be part of the set. Due to the dynamic nature of JavaScript this approach cannot be used in all cases but wherever it applies the speedup is very noticeable. Two performance test cases supplied by Richard Moore and the iBench JavaScript test finished in 13% to 39% less time than before. Quite a bit for a single patch!

If one considers the sum of all the latests improvements done by KHTML hackers from and outside of Konqueror will perform significantly better in KDE 4. iBench and Ian Hixie’s JavaScript and DOM performance tests show a speedup factors of 2, 3 and sometimes even higher! This leads to a clear outperforming of Firefox 2.0 in some HTML test cases.

Above results will not apply 1:1 to every page. Some bottlenecks are definitely still left but will be addressed for KDE 4.0 or later releases.

At the AJAX World conference this week we got a chance to talk to many AJAX developers and vendors of AJAX toolkits. As a result of that we recognized that we need to give users of Squish for Web the possibility to extend Squish for custom AJAX widgets. This means a way is needed to allow to tell Squish how to recognizing complex, custom AJAX widgets for record, interact with them on replay and to give testers access to the widgets’ APIs. And all this with as little code and as much convenience as possible.

Now we already support many complex AJAX widgets, so the necessary framework and abstractions are present in Squish’s code. So only a way to extend this is needed.

Well, on the plane ride back from NYC to Hamburg I had some time to work on this and it was surprisingly easy to create such an extension API. There are still a few features missing but most of what’s necessary to write such an extension is available now.

So one can now add a JavaScript file to Squish which makes use of a public JS Squish API allowing to implement support for special AJAX widgets. As a proof-of-concept I started implementing support for the IT MILL AJAX framework. All standard clickable widgets (buttons, tabs, etc.) are now recognized and the complex IT MILL tree widget is also completely supported. For all of this only ~60 lines of JS code were necessary.

We will complete the IT MlLL support which now also serves as a proof-of-concept that such a toolkit extension can be implemented completely using Squish JS extension API.

This will become a documented feature of Squish 3.2. This way users can add support for their own widgets, AJAX toolkit vendors can offer support for their toolkits and due to the clean separation between the Squish for Web JS kernel and the toolkit widget extensions it is easier for us to integrate, maintain and add extensions for AJAX widgets and toolkits.

Pretty cool stuff in any way and certainly a good way to tackle the issue of the amount of available AJAX widgets and toolkits while still providing a way to allow creating high-level, robust tests working on widgets rather than on low-level DOM (as most other web test tools do it).

The last day of the AJAXWorld Conference and Expo is about to end. Attendees are having their last break with some drinks and cookies before Session 10 and 11 from Track 1 up to 6 will take place.

Interest from visitors at our booth has remained good throughout the three days. Some were still new to the topic of testing User Interfaces, others came by with concrete questions that stemmed from requirements of their application. And we were happy to have been able to positively answer all those questions. Apart from the small number of requests from companies deploying Flash applications. But given our track record it’s probably just a matter of time when a Flash edition will be available.

We also had lots of interesting discussions with other ISVs that are exhibiting their Ajax solutions. The concentration of vendors dominating the market has been extremely high here.

Our flight back to Hamburg is going back late tonight. So we’ll have no stress packing up our things and getting to the airport. Getting some sleep on the plane would be nice but difficult to get as usual. Will give the next sign of life once we have returned and have recovered from the jet lag that we’ll have because our bodies have just been recovering from the jet lag we got from our flight here.

The first day of AJAX World is over and we are now starting into the next day of the conference. After setting up or booth yesterday started rather slow. But people were still arriving until after lunch so that’s ok.

So it was a good time to get to know the other exhibitors and sponsors and see what they are doing. Got to know many of the people behind several of the AJAX frameworks which we support and which we want to support in the future.

After lunch the conference attendees started finding their way to the expo floor and we had plenty to do at our booth. We showed off Squish quite a lot, esp. during the reception after the day at the expo floor many interested people came to talk to us. Having set up a video projector at the both constantly showing a video of “Squish in Actions” certainly worked well.

So let’s hope it will be a busy days today again.

Harri and I arrived yesterday evening in NYC for the AJAX World Expo which will start tomorrow. The flight was one of the more pleasant experiences. Emirates, who flies directly from Hamburg to NYC, really does a good job when it comes to service, food, etc. The on-board entertainment system was also the best I have seen so far. I’ve been playing Mahjongg for the first time in years again so the time went by quite quickly

The hotel which we are staying at in the middle of Manhatten is nice too. But it’s rather cold here esp. compared to the temperatures we had already in Europe.

Earlier today we already checked out the conference location and probably not much will happen today anymore. Jetlag isn’t too bad (ok, I was up at 4:00am already so we will be fit and ready tomorrow to man our booth and take back a lot of valuable feedback and ideas (and leads of course

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.

My favourite IMAP server Archiveopteryx gained Sieve support with version 1.16 that came out last month. Apart from a few small harmless glitches it worked out of the box which finally means the end of client-side e-mail filtering for me. But it took Frerich less than a minute to discover that KMail’s support for managing the rule files did not want to work with the new server component.

After some debugging I discovered that the KIO slave did not even get past the authentication stage. The guys of Oryx were quick to fix the behavior of the STARTTLS and AUTHENTICATE commands but we are still stuck with kio_sieve not accepting the response of a CRAM-MD5 authentication attempt. It wants a {number+}crlf *octet literal but the server simply sends a “….” quoted string.

The server behavior is fine according to the standard draft and before I file a wish to change the behavior to a KMail-friendly one I’ll try to implement the missing part in the KDE client. Might help other users with other servers in the future, too. Guess that the ManageSieve support was never tested with anything but the Cyrus server…

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!).