Testing Pre-Release Software

By Shane Stanley

Testing pre-release software involves some interesting, and sometimes nerve-wracking, decisions. In most cases the best way to test is with a real job, but committing a large job to alpha software can involve a leap of faith. You have to weigh up what happens if it doesn’t work out, what the alternatives are, and even how much faith you have in the developer involved.

Several months back I took on a fairly large project, and this was the process I was going through. In some ways it was a straight-forward scripting job, but what complicated things was the need for a bit of user interface, plus the amount of code likely to be involved. I looked at the options: a series of applets with death-by-display-dialog, or the potential maintenance headache of AppleScript Studio. FaceSpan 5 was at least worth considering, even though it was a long way off release.

I’d already written a fair bit of code in the form of a couple of applets, so the first thing to try was to bring them into FaceSpan and see how much effort was involved.

The process was surprisingly easy, as was adding the basic UI I needed. I could see that things would get more complicated if I wanted to implement non-modal elements such as sheets, with a much more event-oriented approach required, but my immediate goal was to try to get the main basic dialog working. My first impression was one of comfort: the editing and debugging environment were largely similar to Script Debugger, if a little undeveloped in some areas (we’re still talking early development software). So far, so good.

I started running the resulting Facespan 5 apps, and got my second surprise: performance. The apps were mainly targeting InDesign and Illustrator, both of which have a script menu or panel. Anyone who has scripted them knows that there’s a big difference in how fast things happen when scripted from the menu/panel versus an external application. 

But the FaceSpan 5 apps were driving both InDesign and Illustrator more like they were being run from a menu/panel: InDesign stuff happened much faster than when driven from a normal AppleScript applet, and with Illustrator the difference was massive — almost an order of magnitude. This was a big plus for this project.

By now the amount of code was growing, and I had to look at how to manage it. The traditional AppleScript way is to save handlers in libraries, and load them into variables at launch time. 

But libraries involve issues like where to store them, and when it comes to debugging they’re a bit like black boxes. That’s fine when you have well developed code in them, but it can be inconvenient on a project where you’re developing both the library code and the main code at the same time, and the requirements are changing. You end up doing things like putting handlers inside scripts until you have them debugged, and then juggling them — the code management issues start to make the code writing a lot harder.

I was hoping for a better approach, and FaceSpan 5 had it in the bag — objects called bags that are nothing more than containers for holding code.

The advantages of using bags soon became apparent because of another FaceSpan 5 feature, delegation. So I could put some of my “library” handlers in a bag, delegate the bags containing the main code to this library bag, and call the handlers without having to jump through the hoop of loading the bag into a global variable and referencing it that way from then on — I just call dosSomething(), and if there in no doSomething() handler in the bag where it’s called, it just looks further up its delegation chain until it finds one. 

There are a couple of gotchas, but using bags like this really helped me focus on the code, especially at the stage where I was rearranging things and moving stuff about. As a bonus, doing it this way reduces launch time because there’s no need to load slabs of code first — they don’t get loaded until called, and not at all if they’re not called.

The other big advantage of using bags is in debugging: you can step through your script, in and out of handlers in other bags, seemlessly. And having a series of smaller bags of code that you can easily switch back and forth between, without having to worry about what’s in what file or bundle, makes managing a larger project so much simpler. It’s hard to explain, but it seemed to make it easier to arrange the code to reflect how it all interacted.

I still have a wish list, and I still occassionally copy chunks of code into Script Debugger for debugging. At the same time, I’m also moving smaller projects that could happily be done as applets into FaceSpan, largely for the performance gain. And there’s still lots of stuff in FaceSpan I haven’t started exploring. But so far I’m a very happy, and enthusiastic, “tester”.