Thank you and good morning. It's good to see that there are so many people coming to this session because automated testing has been one of my most considered ideas to promote for Mac OS X. So of course, you know, why are we here? Because there's a great need for testing automation. Our applications have become more complex.

Our needs for debugging, we want to reduce our engineering support requirements. And what we want to show you today is two things. One, a solution from Apple that's AppleScript-based functional testing based upon our Section 508 accessibility APIs. And two, a solution that's being provided for us from the Redstone software folks called Eggplant. Which does user-centric testing from a scripted base. And without further ado, let me introduce John Comiskey from the Senior Software Engineer from the AppleScript group.

Thank you, Godfrey. Thank you all for coming. Good morning. My name is John Comiskey. I'm an engineer in the AppleScript group. And I want to talk to you today about GUI scripting. First, a little bit about where GUI scripting came from. Section 508 is a federal law that mandates accessibility features for hardware and software purchased by the federal government. And if you're interested in that kind of thing, you can look at the U.S. government's site about the law itself.

Apple responded to this, being good citizens, by creating an accessibility API. It's in Jaguar right now. You can look at the header files, which is how I learned about it. You can also go to the documentation on the developer website and learn about it that way. If you search for accessibility, you'll get some hits on documentation for Carbon and for Cocoa and for how it should appear to your users if you're working in the accessibility space, if you're building hardware or software to make the computer more usable by people with disabilities.

When we in AppleScript saw this, we realized that this doesn't just have to be an API. It could be available through scripting as well. So we created GUI scripting. It's a suite inside the system events program. If you target your events to system events, they'll be handled there.

And if you want to look at the dictionary, you can open up the dictionary for system events and look in the processes suite. Because GUI scripting has been implemented as an extension to the processes suite. And there's some interesting examples on the AppleScript website. And you can see the URL for that there.

So what is GUI scripting? It's an object model of the current state of the UI at this particular instance, instant. You can access the things that you can see on the screen through a containment hierarchy of objects. Every process on a machine is now also a UI element. In addition to being a UI element, each process is a container for other UI elements.

Every process contains one or more UI elements, usually one menu bar, and one or more windows. And then containment for UI elements is recursive. Inside the windows, there's buttons, sliders, all sorts of things. And you can get all of these by walking down the tree to the object that you're interested in.

Every UI element has a set of attributes. Buttons have titles. Various UI elements might be enabled or disabled. You can get at these attributes as a collection, as elements of the UI element itself. Certain ones that are particularly useful, we've called them out and given them property names so that you can get at them directly. One less step in your hierarchy to get at those.

Each UI element also contains a collection of actions. Those are the things that that UI element can do. So buttons can be pressed, sliders can be slid, and an individual UI element will tell you these are the actions that I think I can do. And if you want to do one of those things, there's a perform verb, and you apply the perform verb to the action object, and the action applies itself to its container, which is a UI element.

So what can you do with GUI scripting? You can access the attributes and actions of all the standard controls on your screen. So you can find out how big a button is, where it is on the screen, whether a menu item is enabled or disabled. You can get at all of that information. And you can use this information to test the user interface of your program, whether your application is scriptable or not. You don't need other kinds of scripting to do this. And this allows you to control the behavior of otherwise unscriptable applications. Whoever would do that.

What it can't do. GUI scripting can't get at any non-standard controls. If your application has a lot of GUI widgets on the screen that you designed and built yourself, we probably won't know anything about them and we won't be able to get at them. They'll just be dead spots on the screen that we can't touch.

The Accessibility API does have some features that allow you to take your non-standard controls and make them behave enough like standard controls that the Accessibility API can see them and work with them. I would strongly suggest you do that if you depend heavily on custom controls and not just for GUI scripting but for accessibility.

We bought into accessibility, you guys should too, and the way you do that is to take your custom controls and make them behave in a little less custom fashion. Another thing that you can't do with GUI scripting is you cannot directly test the object model of your application.

Everything comes in through the user interface. You're actually clicking buttons and sliding sliders. So there'll be parts of your code that don't get touched coming in this way. It's also true that there'll be parts of your code that do get touched coming in this way that don't normally through object model scripting. Object model scripting usually completely bypasses the view and the controller layer. And goes straight to the model objects.

If you use GUI scripting, you'll invoke both the view and the controller before reaching the model objects. So it gives you more testing in some parts of your program, less testing in others. And the last thing, most important message, the reason I'm here is to tell you that this does not replace real object model scriptability in your application. This is not your ticket to blow off scripting.

This is at best a stopgap, and we'll get to some of the reasons why. So how do I use it? First thing you have to do is you have to turn on the accessibility API, which is off by default in Panther, and it is not scriptable to turn it on.

So somebody's going to have to turn on the accessibility API by hand before they can use this. Next thing you've got to do is identify which UI element it is you want to act on. And this can be easy or it can be hard, depending upon how complex the screen is and how deep the hierarchy goes. Then you want to identify what action it is you want to perform on that UI element. And then, last thing, perform the action on the element.

So if you need to enable the accessibility API, you should launch the system preferences, select the universal access pane, and down at the bottom, second checkbox from the bottom is enable access for assistive devices. That's the one you need to turn on or none of this is going to work.

To find the UI element that you want to work on, there's three choices of how to do that. You can write an AppleScript that digs its way through the hierarchy layer by layer until you find what it is you're looking for. This can be hard because there's things on the screen that you can't see. Groups might exist and the thing you're going after is inside the group.

Unless you probe what's inside each group, it's going to be hard for you to find it. There's a couple of tools that make this a little easier. One comes from Apple. It's called the UI element inspector. And you can download that from the AppleScript GUI site. There's another one from the folks at Prefab called UI browser. They're both very good at finding things. The one thing that UI browser can do that UI element inspector can't is it can actually spit out some AppleScript code for you so you don't have to write it yourself.

Then you want to identify what action it is you're going to perform. That's one step down in the hierarchy. So if you've written a script to find the element that you're interested in, then you just ask that element, tell me what your supported actions are. In the UI element inspector and UI browser, if you're pointing at that UI element, the actions will be listed right there for you.

And again, the UI browser can just spit out the code you need to perform one of those actions. Then you want to apply the action, and you do that by applying the perform verb to the action object. And you do that the same way whether you were using scripts or the UI element inspector to find it. And again, the UI browser does it for you.

The accessibility API and GUI scripting support keystrokes. It's always better to set the value of a text object rather than to send it keystrokes. You're going to get the results you're looking for with less hassle that way. But there are some times when you have to send keystrokes, particularly if you're typing into a field that's actually non-standard control. You can still get data into it by sending keystrokes.

Keystrokes are always directed to the object that has the focus. And if you want to change the focus in AppleScript, activate, set frontmost, click, and select are all things that can change the focus for you. And you'll have to experiment to see what you need in your situation to get the focus where it needs to be.

The keystroke verb takes Mac Roman characters and turns them back into virtual key codes. This works pretty well for the English language. It does not work pretty well for other languages. We know that's a problem. We're working on it. The accessibility API group has the same problem that I have, and we're trying to figure out a more robust way of handling this. But for what you've got now, it works well in English, not so well in other languages.

To get around that, to give you an escape hatch, we also have a key code verb where you can send your own raw virtual key codes. Finding out which one to send is hard, but once you find out which one it is, you can send it. And now I'm going to show you how to do this.

Since UI elements is off by default, it's a good idea to test to see if it's on first. The number one source of calls and emails about this from the people that have been working with it so far is that it's been off when they've tried to use it.

So I put a test for that in each of these scripts, and if it's not on, I'm going to I take that there is enough scriptability in the system preferences to take you right to the point where you want to turn it on. And so we're going to do that. And this is going to ask me for a password. And that was it. So now, since we've checked Enable Access for Assistive Devices, the accessibility API is on and GUI scripting will be able to do its bit. Okay.

Now, sometimes I work in a lab and the other people that work in the lab like to take the dock and stick it someplace else. I like it on the bottom. There's a menu item that will move it for me, but that thing itself is not scriptable, but we can get at it with GUI scripting. You notice that I click the menu, then I click the menu item within that, and then I click a hierarchical menu item within that. GUI scripting is very deliberative. You frequently have to traverse the path to something before you can use it.

The edit menu is particularly sticky in this fashion because most of the things in the edit menu are disabled until a selection is made. So you frequently have to step through all the intervening steps to get to your item. You can use the menu item if it's in the menu bar. And it moved the dock.

We did this in the first place because we had a customer that had a dialog that was blocking a workflow. and he just needed to dismiss that dialogue. So one of the things that you're likely to want to do pretty soon at the beginning is dismiss a dialogue.

And again, we make our same check at the beginning to make sure everything is on. Okay, because of the way that text edit works, I have to send a keystroke in order to get the document to be dirty. And so what I'm going to do is create a text edit document, put some text in it, try to quit the application, and it will come up and say, I have stuff to save. And then we'll use GUI scripting to dismiss that dialogue.

I'm using that script editor because I don't have text edit running already. Excuse me while I go out to the finder and get my applications and launch TextEdit. This might work a little bit better this time. There. Put some text in there. Send a keystroke. OK, I'm sorry. It went too fast. TextEdit did close and quit without you guys getting to see the dialogue. I'm sorry about that.

We might try that again, but we'll go on to the third one instead. And here's a script that I've written that sets a preference. In this particular instance, the sound. And it just toggles the sound between two different values, but it shows how a slider can be manipulated. It shows how a preference that's not otherwise scriptable can be accessed.

Yes. Okay. I don't hear a beep. Is that because the sound from the demo machine isn't on? Is that true? Okay. All right, now we should hear it change and be louder. And now it changes again and it's softer. Okay.

Just for fun, let's see if we can get TextEdit to work the way we thought it would.

Quit the script editor. Relaunch the script. We'll try this one more time just to see if we can get it to work. Sorry. It happens too quick. And I seem to have an error as well. But that's GUI scripting. You can use it to test your application. We expect that this is not going to be a good end-user solution. Testers that work for you and you pay them to run the same tests over and over again and change the tests every time you change the code, they'll put up with this.

But end-users are not going to take this as a solution for their problems. So we'd like to encourage you to learn about GUI scripting, use it for your own purposes internally as a test tool, but for your end-users, you should provide them with object model scripting. And now, if we can go back to the slides. I'd like to introduce Doug Simons from Eggplant Software, or from Redstone Software, who's going to talk to you about Eggplant, a much more professional tool for testing your applications.

Hi, it's good to see you all here. There's a lot of people. I'm Doug Simons with Redstone Software, and we're going to tell you about Eggplant, which, as you've heard, is our software test automation tool. So to begin with, why would you test? I'm sure that all of you have a lot of reasons, or you wouldn't all be here at this session. But here's a few ideas that I had. The Mac OS environment is about quality software. Mac OS users expect a good experience with your software. If you deliver crummy software that doesn't work well, you're not going to have a good experience in the market.

Clearly also, there are some cost advantages to you. If your software works well, you're going to have less costs for support calls and your support personnel can spend time answering questions about your program's functionality rather than fighting fires with bugs. So the bottom line, I think this equation speaks for itself. Better software means happier customers. And if your customers are happy, then chances are you're happy too.

So why don't people test? Well, of course, we all do test. And developers, when we add a new feature to a product, we're going to try it out and make sure that it works. A lot of development organizations have a big emphasis on unit and functional tests at a lower level. But testing is a complex process.

If you've added a new feature to an application, chances are it works well on its own, but maybe it's going to have some difficulty interacting with other features of your application that have been there already. So those kinds of interactions, both within your program and with other programs, are important to test as well. So you might want to go hire some people to do this testing for you. And that's great, but of course, it's a costly thing to hire people.

The process of testing is not the most fun always. It's kind of a repetitive and mind-numbing task often. And you might rather have those intelligent people doing something more interesting. So you might want to invest in some test automation software to free up some of your tester's time, make them more productive. Unfortunately, a lot of the software solutions that are out there have been traditionally hard to learn and use. There's a steep learning curve involved. And so it can be difficult to get going and really make use of those.

Let's look at a few different testing approaches. First of all, obviously, is manual testing. Almost everyone does a certain amount of manual testing. And this is good, but it can be very labor intensive. And besides that, people have a tendency to be a little inconsistent. So, if you have a lot of manual testing, you might want to be careful with your manual testing. You might want to be careful with your manual testing. You might want to be careful with your manual testing.

And that's a concern. Even if you've written up test scripts that your testers are following to step your software through various processes, different testers are likely to follow those instructions in slightly different ways. And if you don't have instructions, then who knows what sort of results you'll get from one test run to the next.

So one obvious solution is to automate that process. And in the past, sometimes that's been done through hardware-based solutions. Apple Computer at one time had a hardware testing product, and our own parent company, Gresham, had a hardware-based testing solution also. And hardware testing works great when it works. And the problem is that it can be very inflexible and platform-specific. If the system being tested changes in some way or you're working with different hardware that you're connecting to, it can be rather fragile sometimes and prone to problems.

So obviously a more flexible solution would be to use software. And software solutions can be great, but as I mentioned before, they're often hard to learn and also require integration most often into the software that's being tested. So that's an additional barrier to implementing and using those. We found in talking to people that quite often the expensive software solutions the companies invested in ended up collecting dust in a corner as shelfware.

So, as I said, our parent company at one time had a hardware testing product and about a year and a half ago we started looking at what other alternatives might exist. We abandoned the hardware product, which was PC-based, and investigated what it was going to take to come up with a better solution.

So I'd like to share with you some of the design principles and goals that went into creating Eggplant. First of all, we wanted it to be easy to learn and easy to use. Because we really didn't want to create another piece of shelfware. We wanted people to use our software and get some benefit from it.

We also would like it to be powerful and elegant. Well, those are great marketing buzzwords, but what we mean is that we wanted to focus on the essential functionality that testers needed. and we also wanted it to be flexible so it could be integrated into an overall testing environment.

We also wanted to create Eggplant to be independent. We wanted to minimize the amount of integration required. In fact, no integration required with your software so that you don't have to know ahead of time what you're going to be using to test with, and we can test with any software that's out there. We also thought it was important to be non-intrusive, to have a minimal impact on the performance and behavior of the system where your software is running.

Cross-platform is another important goal because software exists in a multi-platform world. Even if you're creating software for Mac OS X only, chances are that your program these days is going to be working with files from other systems, importing or exporting, and you need to be able to have some way to work with a cross-platform testing environment.

And finally, we felt it was very important to test from the user perspective. As we said, there are a lot of functional and low-level unit-type tests available, but the bottom line is you want to create software that is going to satisfy your users. If you have a wonderful computing engine that does wonderful calculations, but the user interface is crummy or simply doesn't work, your users are not going to get any value out of that.

So how does Eggplant work? Well, first of all, we provide remote control of another computer. How many of you have heard of or used a product called VNC? and quite a few. So, VNC is an open source project that's been out there for a number of years that allows one computer to remotely control another. It does this by displaying the screen of the other computer and allowing you to control the keyboard and the mouse.

So, Eggplant leverages this technology. We've built a VNC client into Eggplant that allows us to talk to any VNC server out there. And as an open source project, VNC is available for essentially any platform that you wish to test. So, we're able to connect not only to Mac OS X but Mac OS 9, Unix, Linux, Solaris and any flavor of Windows. Then we added in scripting. We have a powerful scripting language that allows you to automate any task on any of those systems. So the bottom line is that Eggplant can drive any software on any system through the user interface just like a user would.

So I'd like to invite my colleague Jonathan Gillaspie up now to give you a quick demo of how Eggplant works. Hi there. Thanks, Doug. So for our first demonstration, what I'd really like to show you guys is exactly how Eggplant works.

I'm going to go ahead and make this display a little smaller so we can go ahead and see it easily over on this machine.

Okay. So there we go. That's our remote machine that we're going to test. Now to show you how to go about testing one of your applications, we needed an application to test. So we've gone ahead and created a really simple application. This application is so simple, we decided to name it Very Simple.

So although VerySimple's very simple, I want to go ahead and show you what it does do. So when you double-click and launch this application, it brings up a login panel. And you go ahead and type in your login name. In this case, it's Fred with the password of Wilma.

And then VerySimple goes ahead and brings up a list of some pictures, some interesting pictures. So we'll go ahead and select a picture from the list and click the preview button. And as soon as it does that, it launches that image up in the preview application. And that's about all that VerySimple does. It's just a real simple application to show you something we might want to test. So I'm going to go ahead and quit out of preview and quit out of VerySimple.

So now that you know what very simple that is, I want to go ahead and build a test to make sure that our application works correctly. I do that by creating an eggplant test suite. A test suite is simply a collection of all of the resources that you need to test an application. You can have multiple scripts within a suite, so we'll go ahead and create the first one of those now.

Just like that. Right. From this point, we could actually just start scripting right here in our script window using Eggplant's scripting language, SenseTalk. But instead, I'd like to use Eggplant's script generation capabilities to show you just how easy that can be. So we go into what we call capture mode.

You'll notice that in capture mode, we're no longer interacting with the remote computer directly. But instead, we have a selection rectangle here, which we can use to identify elements of the remote screen that we want to deal with. So in this case, we're going to highlight in on the very simple icon and tell Eggplant that we'd like to double-click on it by choosing double-click from the toolbar.

Eggplant brings up a save dialog, and we give it a name for our image and click save. When we click save, three things happen. The first is Eggplant saves that image in our very simple -- in our very simple test suite. The second thing it does is it actually generates that command into our script. Double click on the very simple icon.

and the third thing that it does is actually execute that command against the remote machine. When it does that, Eggplant goes and searches through the remote screen until it finds the very simple icon and double clicks on it. And you can see here it's gone ahead and launched the very simple application. The next thing we want to do in our script, of course, is click in the name field so we can enter our username and password.

We identify that field by the name label, but of course we don't want to click directly on the name. We want to click to the right of it. We do that by setting Eggplant's image's hotspot. You can set the hotspot anywhere on or relative to the actual image. So we'll set it right there in the field and say click.

Again, Eggplant saves the image, writes that into the script, and you can see now that the name field is selected. Now we'll go ahead and type the username in. We have a type text command, so we can type in Fred. And you can also send special characters like the tab key to go to the password field. And then we'll type in the password. Now we'll go ahead and click on the submit button.

To log in, and up comes our list of pictures. We're going to go ahead and just pick an item from the list. We'll go ahead and pick the chess item again. And click on that. And finally, we'll go click on the Preview button. You'll notice these Aqua pulsing buttons, like preview and the submit button, are pulsing on the screen. Since Eggplant works by finding images on the remote screen, we have a special color matching mode that allows us to locate those images.

There we go. It's messaged the preview application and brought up our image. We want to go ahead and make sure that that image actually came up on screen because that's what Eggplant's all about is validating the results of your application. So we'll go ahead and use the wait for command to do that. The wait for command will wait up to the maximum period of time for the image to come up on the screen. In this case, that'll be eight seconds.

As soon as Eggplant sees that image up on the screen, we know we've successfully completed the test, so we want to go ahead and quit out of preview and quit out of very simple. I'm going to use the type command feature to send a command queue to preview, and that quits out. And then I want to quit out of very simple, and let's go ahead and do that through the menus.

There we go. So as you can see, we've now created our very first demonstration script that tests our very simple application. We have all our script commands here. We have all the images that Eggplant uses right over here. So we can go ahead and run this script. and watch Eggplant step through, log in, highlight that, see the image and quit out.

Thanks. Anytime Eggplant runs a script, it records the results over in the results tab in our suite. So we can click on the most recent run of that script. And you can see here that Eggplant has stored not only every action that it performed, but it also identifies where on the screen it found that image, and it also identifies at what time it occurred. At this point, some of you are probably wondering exactly what it looks like if a script fails. So we can cause a failure by going in and getting rid of the password so we can't log in. And we'll go ahead and run that.

Sorry. Eggplant fails here because it can't continue forward through the rest of the script. So you can see over here in our results tab that the last run is highlighted in red. And if we select that, we see that Eggplant automatically has taken a full screenshot of what the screen looked like at that point and has highlighted the image that it was looking for. By using this, you can quickly see that we weren't able to find the chess item because the authentication failed. So that's a pretty basic look at the easy features of Eggplant. So I'm going to pass it back to Doug now.

Thanks Jonathan. So now you've seen something about how eggplant works, let's take a quick look at some of the technologies that are behind this and the benefits that those give to you. First of all, we have a powerful scripting language called SenseTalk. SenseTalk is a very easy to learn, understandable language.

It's actually modeled after HyperTalk, the language in HyperCard, which probably a lot of you have seen before. We also have added a number of extensions and SenseDoc is a very full-featured, object-oriented language, so it gives you the power that you need to do whatever it is that you need to get done there.

We also use VNC, as we mentioned before, which stands for Virtual Network Computing. And VNC, as I said, is an open protocol, an open source project that allows us to see the screen of the other computer and control the keyboard and the mouse. This gives us separation from the application and system that's under test. As you saw in the demo, we were testing not just the very simple application, but actually the interaction between very simple and the preview application.

From our point of view, there's really no difference. All we know is that there's a screen out there and we can interact with it. This gives us a lot of flexibility, and we not only test interactions among different software on the same system, but even across systems from one computer to another. And finally, of course, this separation allows us to control the system just like a user would.

We also use Cocoa. I'm sure a lot of you are using Cocoa. And we think this gives us some advantages. Obviously, it gives us the clean, intuitive Aqua interface. But also, more importantly, it allows us to be responsive to our customers' needs. We use the XP Extreme programming approach, and we find it's very important to be able to be responsive to the requests of our customers.

Let's take a look at Eggplant as a tool. We see Eggplant as just one component of your overall development process. We know that there are a lot of other tools out there that you use and that you need to be able to integrate with. So, Eggplant is able to interact with other tools that can be integrated into your build process. Eggplant script can be called from the command line or an entire suite actually of scripts, as you'll see shortly. And we also are able to integrate with any reporting tools you might have.

All of the files in an Eggplant suite are standard files. The images we capture are saved as TIFF images. And all of our report logs that we generate are in plain text files that you can load into a spreadsheet or access with another reporting tool that you might have. We're also able to interact with Unix command line tools. As I said, we can be called from the command line and we can also call other command line tools. And the same with AppleScript.

Now here's an interesting point. I don't know if any of you, how many of you are aware of the Apple compatibility labs. Have any of you used those? Not too many hands going up. Apple has this great facility. They've got a number of different computers, dozens really, of all different makes and models, well, all Macintoshes, and running various versions of the Mac OS.

And these are available to developers if you go into their labs in Cupertino, you can bring your software in and test it out to make sure that it works on all the different platforms. Unfortunately, it requires a trip to Cupertino to do that up until now. We've been working closely with Apple to ensure that it's possible for eggplant users to access the labs remotely from the convenience of your own office. And, uh, okay. We thought you might appreciate that. So, anyway, I'd like to bring Jonathan back up for another demo of some of Eggplant's more advanced features.

Thanks again, Doug. Okay. So on our previous example, we saw some of the basic features of eggplant, but now I'd like to take this opportunity to show you some of the more advanced features. So I've gone ahead and built off of the demo that I did just a moment ago and created another test suite, which I call not so very simple.

You'll see that Not So Very Simple actually has two scripts now. Let's go ahead and look at the login script. I've actually gone ahead and just broken out the functionality that deals with having the user log in. As you can see in here, you can pass parameters. Can you guys see that okay? As you can see, you can pass in parameters. In this case, we pass in the name and the password into this script and go through the process of validating the user.

So let's go ahead and look at our main controller script, which is view images. You can see we've added quite a few little extensions in here. The first example is we've created a couple of lists here that we can use to iterate over all of the various logins that we want to validate.

And that's what this repeat loop here is for. It goes through the basic test we've already implemented, but now we want to try it with a whole variety of cases. Here's the login line. You can see where we're passing the parameters to the login script I just showed you.

and then we go forward through the rest of the script. You might also notice that that is within a try-catch loop. Whenever Eggplant detects an error, has a problem, it raises a typical exception, which many of you may be familiar with. And you have a choice. You can either choose to let that exception raise up to the top, and Eggplant will report that as an error, or you can catch it and try to resolve that here.

In the first example I gave, we had a problem when we tried to log in and the password was invalid. What I've done here is set a catch, which will catch and see if the error was because the no password panel came up. And if so, we go ahead and dismiss the password panel and continue iterating through the lists.

We go ahead and log that that password's not valid, but we'll gracefully continue so that we try all of the examples. So let's go ahead and bring up our connection again and try running our more sophisticated script. So here you can see it doing the same thing. I have animation turned on so you can see as it's calling the-- oops.

Well, there you see an example of where Eggplant doesn't work. Let me go ahead and quit out and run that again. There we go. This time I decided to try something new that maybe you all hadn't seen, so I brought up a picture of a G5 because I thought that would be fun.

And actually, I think it blew through it while I was talking, but you might have noticed-- I'll run it again real quickly. It actually brought up on the second login there, that's actually an invalid login.

Okay. One final feature that I'd like to show you guys, and Doug alluded to it a second ago, we have a nice little Schedules tab in our suite. The Schedules tab is useful for building up a batch of scripts that you'd like to run. So you can drag some scripts in there just like that. The Schedules tab has some nice features. You can make scripts dependent on the successful completion of a previous script.

You can enable and disable which scripts you'd like to see running at a current point in time. And you can set up a repeat loop so that you can repeat over that batch a number of times. Another neat feature that the Schedules tab has here is we can actually choose which computer we'd like to connect to to run that.

So I'm going to pick these two computers. and we'll start running. These computers are actually located downstairs in one of the lounges. It's actually the ADC compatibility lounge that they've brought to this facility. But they could just as easily be any computer -- computers anywhere on the Internet that were accessible.

So you can see it running through. There, that log in's not valid. And it cleans it up. So I'd like to point out that although what we're doing here is testing the same script on two different machines, you could just as easily switch your connection in the middle of a single script. And in this way, you could test scripting-- you could test something that runs at multiple points on different machines. and hopefully this has given you a good example of how you might be able to use Eggplant to help test your applications.

Thanks again, Jonathan. So I have just a couple more slides here. As you saw, Eggplant is very useful for testing your software. But because we are automating a process on a remote system, it doesn't have to necessarily just be used for testing software. It could be used for some other things as well. And here's a few ideas that we've thought of and that some of our customers are playing around with.

One is documentation. We know that you all like to document your software. But of course, chances are you've got a lot of screenshots then in your documentation. And as your software evolves, you're going to need to replace those screenshots with up-to-date images. Using Eggplant, you could create a script to walk through your application. And at the appropriate point where you want to capture a screenshot, you can tell Eggplant to do that. We can capture either the full screen or any region of the screen that you want to capture.

We think it could also be useful in training. Particularly, we're working on a feature right now that should be out in the next version of Eggplant to allow you to create a QuickTime movie of any part of your script as it's walking through. This could be great for creating a demonstration movie of your software or a variety of other purposes.

And last of all, of course, system administration is kind of a natural. If you've got an Eggplant machine that can connect to any number of different systems across your network, it could be very useful. It could be very useful for scripting and automating any tasks on those machines.

So finally, I thought that John Comiskey was going to have a slide in there at the end with a quote from Matt Newberg. I guess that came out on his final presentation there. But we thought, gee, maybe we should put in a quote from Matt Newberg, too. So here you go. Here's some good advice from Matt Newberg, who saw Eggplant here at Macworld in January and was rather enamored with what he saw. So now I'd like to invite Godfrey back up to do the wrap up.

Thank you very much, John. So, in summary, what have we got? You know, testing is very important. We know it's very important to all of you. This is just, you know, the beginnings of Mac OS X automated testing. The Redstone product is excellent, is in use by quite a large number of our developers already.

AppleScript's GUI scripting capability gives you a certain level of functional testing, and it's limited in scope. We understand that. We know we need to do more there. But I'm sure that lots of people can create point tests for functional testing using it, and logging output, logging errors, and all kinds of other things. Eggplant user-centric, scriptable, cross-platform, broad scope of capabilities. We've only shown a little bit of it here, and they have lots more things in store for it.

Where to learn more. The AppleScript GUI scripting is the UI element inspector. These are the URLs to get to these components, the UI browser, and of course, just go to the developer site and search for accessibility. You'll get reference to a lot of documentation. Eggplant by Redstone Software. This is their company address and contact information. They have Eggplant CDs available here at WWDC.

They were giving them out at their booth during the course of the conference downstairs. If anybody has not received one, please meet with the gentleman from Redstone. They'll be here after this session and out in the halls, and they'll be able to get some more for you. And also the access to our ADC test labs.

If you have interest in more automated testing, I really request that you come contact me. My email address is right there. We're looking for your input, what fits your needs, what would you like to see. We're looking for where we can improve in this direction. And of course, Redstone Software and Jim Armstrong, who will be up in our Q&A panel. He's their sales engineer and can answer a lot of your questions about access and finding information about their products.

And we're very close to the end of the show, but we thought we'd give you a couple of things to go to, both at the same time this afternoon, unfortunately. But number one, how to write a modern Carbon app, take advantage of the latest techniques and concepts for Mac OS X Carbon applications, and a feedback forum for the Apple Developer Connection. You can give us feedback about the conference, about all the services we provide through the year.