words by patrick

It’s been almost 2 months since my last post, so I thought I’d make a status update on what I’ve been up to.

I finished my 4th year of my program, with one more to go. Next year I’m going to get to take some awesome courses, included another Advanced Artificial Intelligence course and more importantly, my final project / research project. I’m still not sure what I’m going to do for that. Being partial to Mac OS X, I’d like to do something that I could write a nice Cocoa interface for. I’m kind interested in doing something with OCR (Wouldn’t it be great to break all those stupid captcha image fields?), AI, Neural Nets, or HCI (Mmm, pie menus). If you have suggestions please let me know.

This summer is shaping up to be pretty awesome. Although my Google Summer of Code application to write unit tests for Adium was accepted, I had to turn it down as I was offered an internship with Apple. As honoured as I would be to get a chance to work with the Adium team, the opportunity to work at “the mothership” is one of that no CS student can turn down. It is certainly a huge opportunity for me, and I hope to do my best to impress, learn and produce at Apple. That being said, I’m taking off for Cupertino, CA, on Sunday. I’m very excited to meet all the other interns and start work.

Further, I’ve also been lucky enough to receive a WWDC Scholarship. I don’t know how much of the conference I’ll be able to attend while working, but I’ll certainly be around. It sounds like a couple members of the Adium team are going to be there, so if a meet-up happens, you can count on me to get some photos.

That’s all for now, more updates to follow.

Last time I wrote about unit testing Adium, I was actually writing about unit testing Adium.framework - The public API that plugin developers and the like can use to tie into Adium. After talking with David Smith from Adium about some of my other SoC Ideas (such as improving plugin support) I realized that Adium’s API really shouldn’t be considered stable, and that using it as a starting point for unit testing is a bad idea.

That being said, I switched gears and started again, this time unit testing the application itself as oppose to the framework. In hindsight I guess I probably should have started here first, but being familiar with Adium.framework from my plugin development, I assumed that would come more quickly. Wrongo.

Anyways, thanks again to Chris Hanson, his short tutorial on getting unit testing up and running in cocoa apps helped me get started, and everything is now working as expected. When you build the test bundle, it launches the Adium build, executes it’s tests, quits, and reports any failures. Good stuff.

Here’s a bit of what my AIEmoticonPack unit test looks like:

- (void)setUp
{
	fileManager = [NSFileManager defaultManager];
	//NSLog(@"Current Directory is %@/", [fileManager currentDirectoryPath]);

	emoticonPack = [AIEmoticonPack emoticonPackFromPath:[[fileManager currentDirectoryPath] stringByAppendingString:EMOTICONSET_PATH1]];
	//NSLog(@"Testing Emoticon Pack: %@", emoticonPack);

	NSArray *fooarray = [emoticonPack emoticons];
	//NSLog(@"Foo: %@", fooarray);
}

- (void)tearDown
{
	// No necessary tear down.
}

- (void)testPath
{
	NSString *expectedPath = [[fileManager currentDirectoryPath] stringByAppendingString:EMOTICONSET_PATH1];

	STAssertEqualObjects(expectedPath, [emoticonPack path], @"Path wasn't right, should have been %@ but was %@", expectedPath, [emoticonPack path]);
}

- (void)testName
{
	NSString *expectedName = [[[NSString stringWithString:EMOTICONSET_PATH1] lastPathComponent] stringByDeletingPathExtension];

	STAssertEqualObjects(expectedName, [emoticonPack name], @"Name wasn't right, should have been %@ but was %@", expectedName, [emoticonPack name]);
}

- (void)testEnabled
{
	[emoticonPack setIsEnabled:YES];
	STAssertTrue([emoticonPack isEnabled], @"Emoticon Pack isn't enabled by default");
	[emoticonPack setIsEnabled:NO];
	STAssertFalse([emoticonPack isEnabled], @"Emoticon Pack is enabled when it shouldn't be");
	[emoticonPack setIsEnabled:YES];
	STAssertTrue([emoticonPack isEnabled], @"Emoticon Pack isn't enabled when it shouldn't be");
}

Hmm. I really need to write my own wordpress theme.

Adium devs look out, incoming SoC application!

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.