FrogBlog

After finally releasing the beta of our upcoming Squish 4.0 release, I decided to highlight some of the less visible, but very cool, Squish 4.0 features. In this post I’d like to talk about the “injectMacWrapper” feature. Until recently it was even unknown to me

The other day a prospect asked me to present a demo of Squish for Mac to test a well known online meeting software (Cocoa) running on Mac OS X. The challenge here is that the application can’t be started stand-alone, which is usually required so Squish can start it to load the hook into it allowing Squish to connect to the application for testing (listen to events, access objects and properties).

In this case the application can only be started via a web browser when starting a meeting.

So I walked over to Rainer, our Mac expert, if he had an idea how we could support that. And to my surprise, he just pointed me to the example “injection” which can be found in “examples/mac” in Squish 4.0 Squish/Mac packages.

This example basically contains one script which injects the mac wrapper (the Squish hook for Squish/Mac) into a running process and makes the application attachable for Squish that way. Be aware that you have to first open the script and adopt the SQUISH_BASEDIR variable to point to your Squish installation directly. Also you may change the ATTACHABLE_PORTNUMBER if necessary which is the port to which Squish can then connect to attach to the application.

In addition, before starting the application you want to attach to (or the parent process which may invoke it), make sure to set the environment variable DYLD_LIBRARY_PATH to point to the “lib” directory of your Squish package so the Squish libraries will be found.

Now start (or get started) the process you want Squish to attach to later.

Finally run the injectMacWrapper.sh script and just pass the name of the process, as you can find it in the Activity Monitor, as an argument to the script. You will see some output and once it is done, Squish can attach to it at the given port.

Now open the Squish IDE (the new, Eclipse based of course :-)) and go to Squish->Manage AUTs. There add an attachable AUT, choose an arbitrary name and specify the port which you have chosen (or left untouched) in the injectMacWrapper script (specified via ATTACHABLE_PORTNUMBER).

Now you can go ahead and create a new test script and create a skeleton script function such as (assuming JavaScript)


function main()
{
attachToApplication("AttachApp")
snooze(1);
}


where AttachApp is the name you specified as name for the attachable AUT in the Manage AUTs dialog.

Now set a breakpoint on the snooze line and execute the script. When you hit the breakpoint, choose recording, record interactions on the running process and choose end recording.

Using the same method you can insert verifications, use the Spy, insert more recording snippets, etc.

Really a cool feature since it allows to attach to processes which have not been started by Squish or been modified for testing (which is many cases just isn’t possible).

A similar functionality is available in our new “Squish for Windows” edition also combine with other Squish editions so one can e.g. automate a Windows GUI started via Click Once from a web site. Of course also Squish for Qt and Java allow attaching to running applications.

I will talk about these features and cross GUI technology testing more in the next postings.

I was yesterday on my first CocoaHeads meeting in Hamburg. Depending on the counting it was the first or second meeting in Hamburg altogether (see the CocoaHeads bei mindmatters post for the details on the meeting prior to that one yesterday).

It was a nice get-to-gether where everybody introduced himself and where we discussed a bit about how we want it to be in the future. We decided to make the meetings on every first Wednesday of the month. So the next meeting is already next week

In Squish we need to intercept the events when recording user interactions and on play back we have to send the events again. So we have to know some details on how the event system in the toolkits work.

To get those details, it is sometimes helpful if you could actually see the functions an application calls. When this need arised on the Mac, I used to use the Activity Monitor which has the ability to sample the application. This is unfortunately not very exact since the samples happen on certain intervals, so you are never sure if the relevant functions are actually sampled.

But Leopard includes the DTrace facility and the graphical frontend Instruments. This allows you to trace a lot of internals of the application, including the functions an application called.

For example you can create in Instruments a new “instrument” that traces all Objective-C calls: simply choose “Build New Instrument…” from the “Instrument” menu and choose the “Probe” of type “Objective-C”. In the dialog I also chose to record the data for “Function” and “Module”. Then just select a target application and press the “Record” button and all the Objective-C calls (including the call stack) are recorded in instruments.

Pretty useful.

But you can also record C function calls: just create a new instrument, this time of type “User Process”. If you record now, you get all the C function calls. This is getting really big really fast (and as a result it the application gets really slow). So what you probably want to do in this case is to limit the functions recorded. I was particularily interested in the functions called in the CoreFoundation framework, so I entered in the line edit after the “hits” text “CoreFoundation” and now the instrument only records functions called in that framework.

I am long-time vim user. For some years I also use a Mac. Last year I discovered the MacVim project. This is a Cocoa based GUI to vim (so far there was only gvim on the Mac, a Carbon based GUI).

The Carbon gvim is not that great so I sticked to the console vim version. But with the new MacVim, I now have a GUI vim that not only looks much better but also has additional features:

• It has a fullscreen mode.
• Vim’s tab feature uses real tabs instead of ASCII-art tabs.
• There is an ODB input manager that adds an “Edit in MacVim” menu entry to all applications (see Edit in SubEthaEdit for the principle).

There are probably other things, but those are the three I really like. With the “Edit in MacVim” feature, I can now easily write my mails from Apple Mail in vim. Unfortunately, the feature does not work for me in Camino.

Apple has a nice overview of thread communication means in their multithreading documentation (for both, Carbon and Carbon). However, I think the documentation is missing another technique that is very simple.

(more…)

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.

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.