Scott Densmore

Talking at Seattle Interactive Conference, November 2-3, 2011

I have been working on the iOS toolkit for Windows Azure lately. We are really close to another release (check out the develop branch if you are interested in the changes). Nov 2-3 I will be speaking at the Seattle Interactive Conference (SIC) on iOS and Windows Azure. Most of the apps on your iOS device don't live on the device alone and uses services hosted somewhere in the "cloud". Windows Azure is a great platform for hosting the services. The toolkit for iOS makes accessing the services easy and intuitive. The talk will talk through how to do this. Bonus: if you come you can see the rest of this handsome cast.

Official Announcement

Build Numbers in Xcode

Working on a Mac / iOS projects, I have been trying to come up with an easy way to bump versions when it goes out the door for testing or production. Mostly I have been working it out manually, yet that is now fun after the dozenth time. I  started looking around for something that would fit my workflow. I found a couple of posts that help me out.

• From Hacker to microISV: Tagging, Building and Releasing
• Revisiting git tags and building

After reading the two posts (especially the last one), it should be easy to follow what I am doing to bump the versions of the application. It feels natural with the gitflow technique. Download the code from the GitHub project here.

Enjoy!

Unit Test Logging for Builds with Xcode 4 and Team City

One of the things I wanted to do after getting comfortable with the iOS/Mac platform(s) was trying to take my "agile" ways to the platforms (for this post specifically testing). I started learning all this in the Xcode 3 days. I really think with the release of Xcode 4, things are getting much better. WIth workspaces, schemes and better unit testing integration, I believe Xcode 4 is making my life as a developer easier on the platform.

All the code for this project can be found on github here.

Unit Testing

Unit testing is by far the lowest hanging fruit. I spent a good bit of time learning the shipping tools for Xcode (OCUnit). I also spent some time looking at the unit testing tools like GHUnit and Google Toolbox for Mac (GTM), yet I am pretty pragmatic and found that for the most part, OCUnit did what I needed.  The only other tool that I use for testing is OCMock. I know a lot of people also use OCHamcrest for extending the assertion macros, I just have not found I use it myself.

I know a lot of people are using specifications these days to do more user level testing. There are a few projects out there that you might find interesting:

• UISpec
• iCuke
• Instruments Automation Testing (another blog post on this later)

Continuous Integration

This is where the rubber meets the road. Getting your software working on your machine is one thing (and sometimes a hard thing), yet having a repeatable automated build that can build and test your software on another machine is something that makes me feel all warm and fuzzy inside. I have been using JetBrain's TeamCity for a few years now and wanted to get my project building, archiving, reporting unit tests and possibly code coverage (more about code coverage in another post).

Getting TeamCity up and running is fairly straightforward.

• Download the latest version of TeamCity
• Open a Terminal Window
• Change to the directory where you unzipped TeamCity (/Application/TeamCity)
• Change to the bin directory
• Run TeamCity by executing the runAll.sh script (./runAll.sh start)

The hard part was getting the project running with test output, which is what this long winded post is all about.

Team City Project Setup

Using a sample project based on the bowling game unit testing example, here is how the project is setup. This is based on the sample for the OCUnitLogger project. This is a very simple setup and you can make this as complicated (or as easy) as you need it to be.

Setup a Project
I created a project called OCUnitLogger and give it a good description.

Setup a Build Configuration
I created one called Bowling with a description.

Setup the General Settings
I left all the defaults on this one.

Setup the Version Control Settings
I left the defaults on most of these

Setup a VCS Root
I set this to use git and check out anonymously using the default polling policy.

Setup a Build Step
This build step is probably the most important part. Building the project is quite easy. You setup the build to build from the command line using xcodebuild. (You can see usage for xcodebuild using xcodebuild -usage.) I have setup this project to just build all targets for this project. Also, I setup the reporting for my tests as JUnit and where it can find the xml file (more on this later).

Setup a Build Trigger
We want the build to trigger every time a checkin occurs so we set that up.

The Logger

OCUnit works using the NSNotificationCenter. By creating a new object to listen for the events, we can create an xml document that mimics JUnit output.

NSNotificationCenter *center = [NSNotificationCenter defaultCenter];
[center addObserver:self selector:@selector(testSuiteStarted:) name:SenTestSuiteDidStartNotification object:nil];
[center addObserver:self selector:@selector(testSuiteStopped:) name:SenTestSuiteDidStopNotification object:nil];
[center addObserver:self selector:@selector(testCaseStarted:) name:SenTestCaseDidStartNotification object:nil];
[center addObserver:self selector:@selector(testCaseStopped:) name:SenTestCaseDidStopNotification object:nil];
[center addObserver:self selector:@selector(testCaseFailed:) name:SenTestCaseDidFailNotification object:nil];

The new object is called OCUnitToJUnitLogger. I create a static instance and in each notification we generate the required nodes. I am using the Google Data XML node so that this works in both a Mac and iOS project.

static OCUnitToJUnitLogger *instance = nil;

static void __attribute__ ((constructor)) OCUnitToJUnitLoggerStart(void)
{
    instance = [OCUnitToJUnitLogger new];
}

static void __attribute__ ((destructor)) OCUnitToJUnitLoggerStop(void)
{
    [instance writeResultFile];
    [instance release];
}

The output goes to a file called ocunit.xml. You can change this in the OCUnitToJUnitLogger.m on line 88.

It is pretty easy to use. Drag the Logger folder into your project for your unit testing bundle and build. You will also need to add the libxml2.2.7.3 (or the latest) library to your link phase and then add /usr/include/libxml2 to the header search path.

The Bowling Project

The bowling project is a Coca Framework project created with Unit Tests. It is pretty standard stuff. The only thing I did was add the logger to the project  and this is what I get from TeamCity:

Conclusion

This is a pretty simple add to any of your projects. If you are using TeamCity and want to have a good log for your unit tests, you can drop this in and have TeamCity do the rest. If you want to make it better please fork from here and pound away.

Debugging Unit Tests for the iPhone/iPad

Update 8/17/2010

I changed the Environment Variable arguments to make it easier and remove the unnecessary quotes around the directories. I now just use the SDK_ROOT for both DYLD_FRAMEWORK_PATH and DYLD_LIBRARY_PATH variables.

I have been working my way through a new iPhone app. I have been doing this TDD. One problem that I ran into was one of my tests failed, yet I could not figure out how to get it working easily so I wanted to debug my Unit Tests. This should be straight forward, yet it took me a while to figure out using the metaphors and tools of XCode (built in OCTest). I know that many people will say I should use GHUnit or GTM (Google Toolbox for Mac). I have tried both of these and I really don't like them because they don't feel as integrated into XCode (not that any of these tools do but that is another story). I spent a good bit of time searching around for how to do this for iPhone/iPad apps. The following articles are the best I found (although didn't answer the questions completely):

• Apple's Documentation on Unit Testing - This defines the difference between Application and Logic tests.
• Chris Hanson's Articles on Unit Testing - A good overview of unit testing on the Mac with XCode
• A good description of how to do this on the Apple Mailing List
• Another good description at Grokking Cocoa

After reading through these articles and many others I finally came up with the solution. I am using 3.2.3. Most of these articles are talking about earlier versions of XCode. Most of the solutions work (especially the last one). My biggest problem that I wanted to solve is make sure that when I switched SDK (iPhone 4 to iPad 3.2), the custom executable (more on this in a minute), otest, that I used was for the right SDK. Unfortunately, each SDK (Mac OS X 10.x, iPhone and iPad) have their own version of otest. So if I wanted to debug a universal iPad/iPhone application, I needed to point to the right otest.

When you create a UnitTest bundle in XCode, it runs a script to run the Unit Tests when you build that target. If you look at this script (/Developer/Tools/RunUnitTests), you will notice that it figures out what platform you are building for and then calls the RunPlatformUnitTests script. If you go to Terminal and do find /Developer -name RunPlatformUnitTests, you will see that there is one for each platform. Each one of these set specific environment variables and run the correct otest with the bundle passed into the script. Armed with this information and the information I got from the articles I could setup my environment to debug unit tests now.

How to Setup XCode

The first thing I did was add a custom executable to my project (that already had a UnitTest bundle target). I named it otest and pointed it to the otest for the iPhone 4 SDK (you could pick the one for iPad if you want). If you do a find for otest in the Developer directory (find /Developer -name otest) you will see that for each SDK, it is located in the Developer/user/bin/ folder. This was the important part of the puzzle. When you open the general table of your Custom Executable information windows, you will see a drop down for Path Type. Instead of Absolute Path you set this to Relative to Current SDK. This will then allow you to run the corrent otest depending on what SDK you pick.

Once you have this part, the rest is just setting the environment variables and the arguments for otest. You will need to pass the name of your unit test bundle (mine is UnitTests.octest). Optionally you could pass what test(s) you want to run, but I take the default to run them all. The only thing about the environment variables is that you will need to use quotes if there are spaces when things get expanded. I am not going to try and discuss each one, I leave that as an exercise for the reader. Here is the setup I have:

Once this is setup, you can debug your Unit Tests. As mentioned in the Grokking Cocoa article, you can clone your unit test bundle and remove the run script so you can build and debug at the same time, I don't ever do this. If your tests fail after building, you can just do a run debug and still debug without building again. I find this easier than managing another target.

Name	Value
DYLD_ROOT_PATH	$(SDKROOT)
DYLD_FRAMEWORK_PATH	${BUILD_PRODUCTS_DIR}:${SDK_ROOT}:${DYLD_FRAMEWORK_PATH}
IPHONE_SIMULATOR_ROOT	$(SDKROOT)
CFFIXED_USER_HOME	$(HOME)/Library/Application Support/iPhone Simulator/User/
OBJC_DISABLE_GC	YES
DYLD_LIBRARY_PATH	${BUILD_PRODUCTS_DIR}:${SDK_ROOT}:${DYLD_LIBRARY_PATH}
DYLD_NEW_LOCAL_SHARED_REGIONS	YES
DYLD_NO_FIX_PREBINDING	YES

Hope someone finds this a useful.

Listened to: Become The Catalyst from the album "The Fall Of Ideals" by All That Remains