How do you test your Cocoa GUIs?

Question

I would like to write some tests for the GUI of my Cocoa program.

Is there any good GUI testing framework for Cocoa apps? The only thing I found is Squish, which, at 2.400€, is well beyond my budget…

Any ideas? How do you test your Cocoa GUIs?

Answer 1

You might check out and consider Eggplant by TestPlant (formally Redstone Software) at http://www.testplant.com/.

Here is an article that Apple featured on them last year.

Answer 2

I would suggest you take a look at Google's Toolbox for Macintosh. It has, among some other nice goodies, a very nice set of state and rendering test additions for NSView and CALayers. In your unit tests you assert that the view/layer state or rendered image matches a saved (by name) template. If the template doesn't exist in the test bundle or doesn't match the saved version, a new encoded state or rendered TIFF is produced for review. GTM provides categories for NSView and CALayer to do state encoding and rendering. Obviously you can override these categories on your own NSView or CALayer subclasses to encode relevant state (using the NSCoder protocol) or rendering.

It also allows you to (easily) programatically send key events and run the run loop from with unit tests and it supports unit testing on both OS X and iPhone.

Answer 3

The latest CocoaCast podcast has an interview with Ian Dees the author of "Scripted GUI Testing with Ruby". You can find out more at CocoaCast

Answer 4

It depends on what you mean by "testing Cocoa GUIs."

If you want tools like the old Virtual User tool included with MPW, then those are few & far between; you'll be looking at tools like Squish and Eggplant.

If you want to write unit tests for your application's human interface, I suggest you follow a "trust, but verify" approach where you trust that as long as you're making the right connections (according to your framework) that your user can interact properly with your framework. That means you can do the majority of your testing by verifying your model and controller code are hooked up to your views correctly.

On my weblog, I've written a couple of examples of how to do this specifically with Cocoa, one for testing user interfaces built with target-action, and one for testing user interfaces built with Cocoa bindings. (Remember, of course, that the two technologies aren't exclusive: If you want to do drag & drop in a table view managed via Cocoa bindings, you'd also have a data source and probably a delegate hooked up via target-action.)

The thing I don't write unit tests for — generally — is the positioning or type of controls in their superview. Sometimes that is important to get and keep correct, however; in that case, I can just query the appropriate properties of the controls and verify them using the standard assertions.

What I virtually never do is write code to "simulate events." The closest I've ever come to that is constructing a fake drag info object and passing that to an outline view data source to ensure it will deal with drags correctly.