Archive for the ‘Squish’ Category

Complex Testdata in Squish

Monday, June 25th, 2007

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.

(more…)

Extending the script bindings for Java

Tuesday, June 12th, 2007

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

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

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.

Hello from the JAX 07

Wednesday, April 25th, 2007

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

Squish Qt Webinar

Friday, April 20th, 2007

This week we held 2 webcasts in cooperation with Trolltech about testing Qt applications with Squish. Doing such a webcase was certainly a new kind of experience. It is very different from an actual talk at a conference or an on-line conference with prospects where you present a product.

The reason is that you don’t really get any feedback during the webcast (unlike on-line conferences, which usually are rather interactive and actual talks where you see the audience). So during the presentation you don’t really know if anybody is still listening :-)

But given the questions afterwards, attendees were able to follow the live demonstration well and the feedback was really good. So this was a good experience and we certainly will do Squish webcasts on a more regular basis now to give evaluators and prospects a chance to see how Squish can be used efficiently.

Meet us at the JAX

Friday, April 20th, 2007

Next week we will be exhibiting at the JAX in Wiesbaden – one of the largest German Java conferences.

We will show our new Squish for Java edition and also Squish for Web since I expect to meet many people doing Java backend/Ajax frontend there. In addition I will give a talk on automated cross-platform testing of Java GUIs (Swing, SWT, etc.) on Thursday in “Saal 12d” at 8:30 in the morning.

So if you happen to be at the JAX make sure to stop by our booth and at least grab one of our infameous frog candies :-)

Squish for Mac Testing with Carbon Support

Tuesday, April 17th, 2007

When we pre-announced Squish for native Mac OS X testing, maybe half of the people being interested in it, were developing with Carbon. At that time we had Carbon on our todo list, but nothing was implemented yet, since we believed that Cocoa was the more popular toolkit.

It seems that we were wrong. So we decided to give Carbon support a higher priority and I started working on it. The work on it progressed smoothly and after implementing the object model for Carbon (based on the HIObject/HIView classes), I was soon able to record simple mouse clicks. Today I finished the replaying of mouse clicks.

So now, it is possible to record and play back the first tests for Carbon applications. Much is left to do, though (the object model is very basic, recording of other events than mouse clicks, etc.); but still, we reached a point that shows that there are no unsolvable technical obstactles left — what’s left is just to implement the missing features.

One of the nice things Apple did, was to make it easy to mix Carbon and Cocoa into one application. So we don’t need separate wrappers for Carbon and Cocoa; and the tester does not have to specify what toolkit the application uses. The same binary just works for Carbon-only, Cocoa-only and mixed-Carbon-Cocoa applications (it works for both, Carbon-in-Cocoa and Cocoa-in-Carbon).

But now I have to go back to do some hacking, so that you can get your hands on this soon.

Extension API for custom AJAX/JS widgets for Squish for Web

Friday, March 23rd, 2007

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

Synchronizing with Backbase Applications

Thursday, March 15th, 2007

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.