OS X part of the book

Please tell me the OS X part of this book doesn’t use some sort of applescript bridge/apple event type of thing….:(
It seems everywhere I look OSX is stuck with applescript a verbose aggravating old #$@&^%… It’s supposed to be easy to use but is probably the hardest thing to grasp as a language and useless outside of the Mac OS. The only reason I understand it. Is because I have too… I’d really rather use ruby as an all purpose utility language to create a domain specific automation language for the Application Under Test . Somehow I’m betting this book will have one small chapter designated to OS X and it will require an understanding of applescript … ugh. Which I’d love to read but it would really make the rest of the book obtuse for me to filter through to find out what is useful. I hope hope hope it’s more than that … I’ll probably buy it anyway. Just needed to vent. I would love to hear what other people are doing for GUI automation for OS X . Besides egg(” I cost 4 million dollars” )plant. Sorry for the rant. I look forward to the publication no matter what.

Hi, gb.

Please tell me the OS X part of this book doesn’t use some sort of applescript bridge/apple event type of thing It’s supposed to be easy to use but is probably the hardest thing to grasp as a language

I hear ya. For me, AppleScript has been much more of an adventure to write than to read. Finding just the right combination of tell application "foo" / do something with "baz" / end tell, even with an app’s script documentation open right there next to the editor, can be a bear. But afterwards, people look at the script and say, “Oh, I see what that does.”

To answer your question, you don’t need to write any AppleScript to use the examples in the OS X chapter. The technique uses a bridge under the hood, but you’re writing Ruby. And I don’t mean one big script_eval() method that expects you just to hand off a big string to it. You’re literally writing plain Ruby code, like edit.menu_items['Paste'].click—but even that level of code gets organized into something clearer, which gets to your next point:

I’d really rather use ruby as an all purpose utility language to create a domain specific automation language for the Application Under Test

That’s exactly the approach the book recommends. Whether the underlying technology is AppleScript or Win32 API calls or what have you, the important thing is that you’re building up the language toward your application. So instead of that menu_items call above, you’d eventually just be saying something like document.paste, and letting the library deal with whether it’s a menu item, a keystroke, a right-click, or a random selection of one of those.

Somehow I’m betting this book will have one small chapter designated to OS X and it will require an understanding of applescript

There’s one chapter specifically on OS X testing, but the entire first half of the book builds up cross-platform tests that run on OS X. All that material on writing clear test language is applicable, no matter which GUI library is doing the heavy lifting underneath.

You won’t need to know AppleScript syntax per se. You’ll be coding to the System Events API, but all in Ruby. A bit like the way Web apps use the RMagick library as a wrapper around ImageMagick, without needing to contain any C code themselves.

Sounds like this book is what I’m hoping for ! I’ll be digging into this soon.

hmmm, before people flame me, I would like to say that I own a lot of pragmattic progammer books, but I just felt compelled to send this email to the support desk

Hi,

I am a long standing purchaser of pragmatic programmer books and have recently taken to buying betas online. I was very excited to see that “Scripted GUI programming with Ruby’ is now available as a beta PDF because it is described as

‘If you need to automatically test a user interface, this book is for you. Whether it’s Windows, Mac OS X, Java-based or a web app, you’ll see how to test it reliably and repeatably.’

I use macs exclusively and so am extremely disappointed to discover that out of a 182 pages only 10 are about testing on the mac (in a tagged on chapter near the end called ‘One Last Thing: Testing on the mac’). This chapter is also more about applescript than ruby as far as I can tell.

The book is essentially a windows only book and therefore useless to me. I am therefore asking for a refund. Please let me know when this has been put through.

Conrad Winchester

I’m a bit lost as to ‘First half of the book builds up cross platform tests that run on OS X’. Pages 20-86 (the first big example) are entirely windows (with a tiny bit of JRuby/Swing for ‘cross platform’ purposes erhm) only. I have never used JRuby and don’t want to test swing apps (swing??? lol – who uses that any more?). I would like to test either cocoa or flash (air/flex or whatever) applications on my mac – this book is useless for that.

There’s a bit on we testing, but thats not really anything new, and then its back to windows with (as I said above) only 10 pages explicitly about testing on a mac.

I am so disappointed.

Hi, Conrad.

I’m sorry to disappoint. :-/

As you and gb have observed, there is only one chapter that’s Mac-only, as a jumping-off point to OS X testing. I’d hesitate to characterize the book as Windows-only, though. Only one chapter (Chapter 7) is limited to Windows readers (well, and a short appendix).

The point of doing an extended desktop example over the first half, and giving equal treatment to both Windows and the JVM, is to quickly transcend the platform-specific calls and get to the test language. Testing a Cocoa app uses the same principles: you start with the accessibility API (which is far simpler than Win32, and requires fewer pages to introduce), and build a DSL for your app.

Just bought this. OK so at first glance it seems a bit thin like most of the tutorials out there. It uses text edit and I suppose on OSX people can automate the @*%# out of text edit. Assisted Testing on OSX is hurting unless you like convoluted applescript. I’ve tried rb-appscript which seems to be the only alternative . Active development on RubyOSA seems infrequent at best. Wonder if any one could write a book on doing some real challenging stuff with these ruby drivers. I’d have more faith if I could see something like a drawing program automated. Not just itunes and textedit. with that being said. I still commend you on writing a book on GUI scripting at all and automated scripting/assisted testing. Not many resources on the subject. Out side of really expensive solutions there is little information. I’ve used eggplant I like it but it’s expensive and you learn a language that does you no good elsewhere. Kind of like applescript. Which is why I wanted to learn ruby or python and would prefer ruby to python. forg logi squish is interesting but is python only or javascript and OH yeah expensive. Automator is powerful but still a toy and a pain if what you want doesn’t exist. The one thing that is handy I guess is the watch me do. I’ll dig into this book and see what I learn hopefully I can get a little closer. Also would like to encourage a podcast on the subject like the ruby object model and meta programming I’d pay 5 bucks for a few podcasts on OSX GUI scripting. hint hint

Hi, gb.

I agree with you that it would be fun to take on a bigger OS X app. What kind of program did you have in mind? Give me a shout (undees at gmail), and let’s kick a couple of ideas around.

—Ian