Jason Foreman

OCUnit XML File Output

2009-10-24T00:00:00+00:00

In the world of Mac OS X programming, OCUnit reigns supreme as the unit testing library of choice. Apple has put a great deal of work into ensuring that OCUnit is tightly integrated into the standard development workflow with Xcode. Unfortunately many other tools–such as continuous integration servers or test metric tools–expect test output in an XML file, typically in the format of the jUnit output from the Java Ant build tool. OCunit does not provide xml file output by default, but adding support for it is quite easy.

The Goal

Build servers such as Hudson have the ability to process test output and generate trend graphs and notifications. Most such tools rely on having the output in a particular format, often the jUnit format. OCUnit by default only prints its output to the console.

The jUnit XML format produced by Ant is horribly undocumented. It does seem to be a rather simple format though, which basically looks like this:

<testsuites>
    <testsuite name="MyTestSuite">
        <testcase name="MyTestCase.testFooMethod"></testcase>
        <testcase name="MyTestCase.testBarMethod">
            <failure>Exception, blah blah blah</failure>
        </testcase>
    </testsuite>
</testsuites>

The Means

OCUnit does offer a few hooks which can be used to follow test execution. A quick peek around the SenTestingKit framework headers–found in /Developer/Library/Frameworks/SenTestingKit.framework/Headers– shows a couple of obvious ways to watch test execution. The first is the SenTestObserver class, and the second is a collection of NSNotifications that SenTestObserver is presumably based upon.

SenTestObserver

The SenTestObserver class defines a set of methods that will be called at the beginning and end of both test suites and test methods. This looks like a perfect solution, but it is completely non-obvious how to actually use a subclass of SenTestObserver. Also, there are at least some reports that SenTestObserver is broken.

Notifications

Since there appear to be some issues with using SenTestObserver directly, the next step is to directly observe the set of notifications upon which it is based. The following notifications are defined in the SenTestingKit headers:

SenTestSuiteDidStartNotification
SenTestSuiteDidStopNotification
SenTestCaseDidStartNotification
SenTestCaseDidStopNotification
SenTestCaseDidFailNotification

Using these notifications it is possible to create a class that can write to an XML file as test execution progresses. The only interesting task remaining is to load the class before test execution starts, which is easily accomplished using a gcc constructor attribute.

The Result

BPOCUnitXMLReporter is a small bit of code that records OCUnit test execution and writes it to an XML file. The code, along with a small sample project, is available on github and can be easily added to any OCUnit test bundle. Simply add the BPOCUnitXMLReporter.m file to the test bundle target, and every time the tests run a file ocunit.xml will be written with the test results. Contributions are certainly welcome, so fork away!

Run Ruby Script Automator Action

2008-01-12T00:00:00+00:00

In a recent blog post, Jonathan Wight unveiled a custom action for Automator which can run Python code. His code uses PyObjC to allow the action to take advantage of all the Cocoa goodness that comes with it. While I am doing more Python work these days, my heart still belongs to Ruby, so I was compelled to respond with a “Run Ruby Script” action of my own.

The source code for this project is available under the MIT license. Like Jonathan’s Python original, this action includes a (rather naïve) syntax highlighting NSTextView. More on that perhaps in a future post. But the real star of this action is the integration with Leopard’s Scripting Bridge.

When Automator passes objects in to a custom Cocoa-based action, it converts them into one of a handful of possible Cocoa types. Types such as strings (com.apple.cocoa.string), paths (com.apple.cocoa.path), and URLs (com.apple.cocoa.url) are happily handled for you. Everything else can be sent as an Apple Event descriptor (com.apple.applescript.object). That’s all well and good, but I haven’t the foggiest what to do when my script receives an NSAppleEventDescriptor. What we really want is an object with methods and properties that can be used to access the underlying object directly. With the help of Scripting Bridge, this is no problem at all.

The Scripting Bridge essentially wraps the scriptable interface of an application up into a nice Objective-C object. With the help of RubyCocoa, we can take advantage of those nicely wrapped interfaces in the “Run Ruby Script” action. Since incoming data is passed in the form of an NSAppleEventDescriptor, the action performs some conversion in order to get a Scripting Bridge object for use by the script. By recursively traversing the descriptor, we can glean the source application and attempt to create an SBApplication. If that goes well, we work our way back up through the event descriptor, finding items in collections on our way back up. This is best illustrated by an example:

Imagine that we ask iTunes to find all songs whose name equals “The Salmon Dance” (a great song recently recommended by Cabel). We might normally get an NSAppleEventDescriptor such as

<NSAppleEventDescriptor: 'obj '{ 
    'form':'ID  ', 'want':'cFlT', 'seld':3592, 'from':
        'obj '{ 'form':'ID  ', 'want':'cLiP', 'seld':3322, 'from':
            'obj '{ 'form':'ID  ', 'want':'cSrc', 'seld':42, 'from':
                'psn '("iTunes") } } }
>

I don’t know about you, but my brain lost interest at 'want':'cFlT'. But let’s not give up yet. After invoking the powers of Scripting Bridge, we get

<ITunesFileTrack @0x12a5c40: 
    ITunesFileTrack id 3592 
    of ITunesLibraryPlaylist id 3322 
    of ITunesSource id 42 
    of application "iTunes" (98938)>

That gives me a warm fuzzy.

Download the action now! If you find it useful or come up with an interesting use for it in a workflow, drop me a line or leave a comment here. I’ll be updating the repository periodically with improvements and examples.

Words of warning: There may be some issues if you have both the Ruby and Python script actions installed. Specifically, Automator may crash if you try to add both actions into the same workflow. I described the problem in brief in my article about RubyCocoa bundles, and Bill Bumgarner described it in a bit more detail on his blog. The bug which causes this will hopefully be fixed in 10.5.2, but I may release a custom built version of RubyCocoa in the meantime if there is enough demand for it.

Loadable bundles using RubyCocoa

2007-12-29T00:00:00+00:00

With the arrival of Leopard, Apple seems to be making a push to support Cocoa and Mac OS X development in languages other than Objective-C. They ship both the PyObjC and RubyCocoa frameworks, and include several Xcode project templates for creating applications built upon these frameworks. But what they forgot are the templates for building bundles that use these frameworks.

Initializing RubyCocoa

If we take a look at the boilerplate we get from creating a new application using the “Cocoa-Ruby Application” template, we see the following in main:

return RBApplicationMain("rb_main.rb", argc, argv);

This call performs any necessary initialization of the RubyCocoa bridge and then loads the specified Ruby script (rb_main.rb). The Ruby script then sets up a few load paths and eventually ends with a call to NSApplicationMain. This works quite well for an application, but we can’t get away with this in a loadable bundle. Thankfully the RubyCocoa authors are ahead of us, and have provided the RBBundleInit call.

RBBundleInit performs a similar function to RBApplicationMain in that it performs any necessary RubyCocoa initialization and then loads a specified Ruby script. The parameters for this function are slightly different, so let’s examine a call and break it down:

RBBundleInit("ruby_bundle.rb", [MyRubyBundle class], nil);

The first parameter is obviously the Ruby script to execute. The second parameter is a class, which RubyCocoa uses to find the bundle containing the specified Ruby script. This parameter may be nil, in which case the first parameter would need to be an absolute path. If the second parameter is not nil, then RubyCocoa searches for the bundle containing the class, and appends the bundle’s resources path to the Ruby load path. The third parameter is simply passed as an argument into the loaded script.

Caveats

There are currently (as of 10.5.1) a couple of issues that unfortunately might discourage anyone from actually shipping a bundle written with RubyCocoa, depending on what application might be loading the bundle.

In the currently shipping versions of PyObjC and RubyCocoa, classes are created in the Objective-C runtime when either framework loads a bridge support file which contains inline functions. Because of this, only one framework can safely be loaded into an application at any time. Bill Bumgarner has written a great example application which combines both PyObjC and RubyCocoa in a single application, and describes this problem in greater length.

This means that writing bundles which are loaded into applications for which you as the developer do not have complete control is unpractical. This includes System PreferencePanes, Automator Actions, Address Book plugins, and more.

The good news is that this has already been addressed in the trunk of the PyObjC Subversion repository. And I hope that it will also be addressed in RubyCocoa the same way. With any luck, these fixes will be included in the 10.5.2 update (anyone with the seeded version who can verify?).

RubyCocoa templates

In anticipation of the aforementioned bug being fixed, I’ve started preparing some Xcode project templates for loadable bundle projects built with RubyCocoa. At the time of this writing, templates exist for both a generic loadable RubyCocoa bundle and a RubyCocoa PreferencePane. Eventually I may add a couple other templates such as Frameworks or Address Book plugins.

The templates can be found in my Google Code repository.

To install these templates, simply copy them to ~/Library/Application Support/Developer/3.0/Xcode.