18th Mar 2007

Unit Testing Adium (Part 1)

With Google’s Summer of Code roaring up again this summer and me without summer job plans yet, I have dug into investigating one of the project ideas by my favourite OSS project, Adium. The project idea I’m looking into submitting a proposal for is that of unit testing much of Adium’s code. Currently Adium does no unit testing. Although my experience with Cocoa is growing to a point where I am fairly comfortable with it, my experience with unit testing doesn’t stretch as far. It’s not a difficult concept, however, so I decided to try and put it into action and see what I could come up with.

I chose to write a unit test for the emoticon classes, AIEmoticon and AIEmoticonPack. I choose these classes because they are documented, making understanding them quicker and easier, and because they aren’t ridiculously large. A good start for a unit test.

Creating a new test bundle target and the test classes were easy thanks to the fact that OCUnit is bundled with Xcode. As soon as I added the necessary frameworks though, I ran into a problem.

Adium.framework references FriBidi.framework, but because the unit test actually runs from /Developer/Tools/otest, the FriBidi.framework isn’t found in the @executable_path (where dyld is looking for it). Copying it to the build products Frameworks directory is no help since it doesn’t look there either. You could create a symlink to the build products directory but that’s rather messy and Xcode provides us with a much easier way of doing this: In the Run Script phase of the build process for your Test Bundle target, define DYLD_FRAMEWORK_PATH to the directory containing your referenced frameworks before the tests are run. Mine looks like this:

export DYLD_FRAMEWORK_PATH="${PROJECT_DIR}/Frameworks"

I spent several hours figuring this little detail out. Big thanks to both Peter Hosey and chanson of #macdev for helping me nail this down and explaining it to me.

I now have the beginnings of a working unit test of AIEmoticonPack. I’ve run into a new problem where certain methods cannot be tested since they require a running instance of Adium. I plan to address this by defining a base test class which instantiates such an Adium instance then changing my test case to inherit from that class. We’ll see how it goes.

One Response to “Unit Testing Adium (Part 1)”

  1. Chris Hanson Says:

    Glad I could help!

    Check out my blog post on unit testing applications if you want to write tests against a running Adium, as opposed to against the Adium framework.

    — Chris Hanson, aka “chanson of #macdev”

Leave a Reply