@Lathi.net

Unit Testing and Mocking for iPhone Apps

Posted by Doug Fri, 06 Feb 2009 20:54:00 GMT

This was so much harder than I expected it to be. I’m new to Objective-C, but a long time TDD-er with Ruby. Being able to write unit tests and mocks is an integral part of any language I work with now. After much searching and trial and error I got it to work.

First, starting with a new iPhone application I followed these directions on how to get it setup. The Sen:Te guys are who wrote OCUnit in the first place. There are other directions out there, but don’t let them lead you astray. XCode 3 doesn’t support unit testing iPhone applications out of the box. Most of the directions for setting up unit testing is for straight Mac OS X Cocoa apps and not iPhone apps. The gist of the directions are:

• Add a new target based on Mac OS X Cocoa Unit Test Bundle.
• In the new test target’s inspector window, whack all the “User-Defined Settings” in the new build tab’s settings.
• Also delete the ‘‘Other Linker Flags’ setting.
• In the General tab, add a dependency to the SenTestingKit.framework. Here’s where it gets tricky. Don’t just add any SenTestingKit.framework. You need to add the one from:

I also added a “Unit Tests” group/folder to the project as a place to store my tests separate from my classes. When you want to create a new test, you simply add a new file and choose the “Objective-C test case class” template. Make sure you add it to the test target and not your main application target.

So that gives you unit tests so you can make assertions; but that’s about it. You also need OCMock. I had a little trouble getting this installed and working, but following Mitchell Hasimoto’s notes I was able to get it working. Download the OCMock framework and save it into /Library/Frameworks. Then in you test target’s inspector add it as a dependency. That should be enough. Here’s a little test class that I used to prove to myself it was working:

testTruth.h:

#import <SenTestingKit/SenTestingKit.h>

@interface testTruth : SenTestCase {

}

- (void) testTruth;
- (void)testAcceptsStubbedMethod;

@end

TestTruth.m:

#import "testTruth.h"
#import <OCMock/OCMock.h>

@implementation testTruth

- (void) testTruth {
    STAssertTrue(1 == 1, @"Must be true");
}

- (void)testAcceptsStubbedMethod {
    id mock = [OCMockObject mockForClass:[NSString class]];
    [[mock stub] lowercaseString];
    [mock lowercaseString];
}
@end

Posted in Programming, Test Driven Development | Tags iPhone, mocks, testing | no comments

In the Fishbowl

Posted by Doug Wed, 08 Mar 2006 13:43:13 GMT

At last night’s XP Cinci we did an interesting exercise called “The Fishbowl”. Mark Windholtz setup his powerbook with a terminal, Safari, TextMate and a time tracking application he had been working on. We then each took turns pair programming on the big screen. While there were two of us “at the console” all the time, we swapped one of them out every 10 minutes.

The exercise was interesting for several reasons. Mostly it turned out to be a good example of what test driven development looks like in Ruby on Rails. The skill level of xp-cinci is split pretty evenly. About half of us have done significant RoR development and the other half is either just interested or just learning. Regardless of skill level though, no one was going to code in public at an XP meeting without writing tests. The best way to learn TDD is by doing. Until you’ve lived through the development cycle of TDD it’s hard to really grasp what it feels like.

The other benefit from the exercise was a fairly lively discussion on “this is how we do it in Rails” versus “this is what I’m used to in Java.” Most of xp-cinci comes from a strong Java background. Even though about half of us are “ruby nubies,” pretty much everyone has a very strong developer background with one technology or another. Here’s a for-instance. I coded up a method that used MyModel.find_by_id(params[:id]) and was asked why I used find_by_id rather than just find. I said that I liked how find_by_id returned nil so I could use it as a false value when doing error checking. As a long-time Java smart-guy, Ed Summerfield was pretty quick to jump on this as a bad practice. He demonstrated how his Rails controllers looked using begin and rescue. I’m not entirely convinced that assigning nil to an object as a fail condition is bad, but his code looked fairly neat with all his error trapping in rescue blocks.

While the skill levels of various members varied, our application we worked on wasn’t really the typical “hello world” style application of tutorials. We started with a working application. Mark and Scott are actually using the application as part of their consulting work at Rails Studio. This gave us the chance to work in a more “normal” fare. We had an existing database we were migrating; we had existing code we had to live within; and we had a “real” customer looking for “real” improvements to their application.

Last night’s meeting was different from our usual fare. It was back to a hands on style where we actually wrote code. While we didn’t get very far in terms of feature points, I think we made a lot of progress in general understanding of both coding practices and Rails development. I hope we continue doing more and talking less.

Posted in Programming, Test Driven Development, Ruby on Rails, Community | Tags Cincinnati, Rails, Ruby, testing | 5 comments

Presentations? We don't need no stink'n Powerpoint!

Posted by Doug Wed, 01 Mar 2006 22:51:06 GMT

I gave a “bootcamp” style presentation today at work on Test Driven Development on Rails. I was struggling to figure out what tool to use to actually compose and give the presentation. S5 is a tool from Eric Meyer that uses XHTML, Javascript, and CSS to make a web-based presentation. It’s really cool. Rather than all the typing needed to write valid XHTML, I wrote a Ruby script to convert Textile to S5. I’ve included the Ruby code needed and my TDD presentation.

BTW, you can view the live presentation here

Posted in Programming, Test Driven Development, Ruby on Rails | Tags Ruby, testing | 8 comments