iPhone SDK: Testing UIApplicationDelegate with OCMock

Ivan Moscoso, Thursday, January 1, 2009 @ 2:12 pm

As I have discussed earlier, you can go very, very far in unit testing your view controllers using the following recipe, without the need to bend over backwards or employ any mocking frameworks:

1. Initialize the view controller in your setup using initWithNibName:bundle:.
2. Force the view to initialize by invoking the controller's loadView method within your setUp method.
3. Write tests to assert dependencies or behavior.

This works well enough for view controllers, but when it comes time to test your application delegate, this simple approach can begin to break down. Unlike UIViewController, your application delegate is only initialized as a by-product of loading the NIB. Thus, to get this code under test I find OCMock particularly useful.

I show an example unit test below, and discuss how I approached the problem..

Background

The UIApplicationDelegate protocol defines a series of optional methods which allow you to respond to application-level events. While the app delegate will not contain much code, the code it contains is certainly important enough to test. The problem however is that the delegate is initialized as a by-product of UIApplication itself.. something which, if you build your project using one of the predefined templates, is performed as MainWindow.xib is loaded. Unlike the recipe above, however, you might find issues (this boils down to a chicken & egg problem, as there can only be one instance of UIApplication at a time, so loading MainWindow.xib as part of a test can present problems when you are running in debug mode).

The Code Under Test

Let's look at a test case that uses mock objects instead. Here I have chosen to test a simple, navigation-based application. The default application delegate essentially contains the following code:

- (void)applicationDidFinishLaunching:(UIApplication *)application {
	[window addSubview:[navigationController view]];
	[window makeKeyAndVisible];
}

If you're familiar enough with this example, you'll know that this method is invoked by the framework. It is also the point in time in which you can initialize anything which needs to be initialized on startup (note that navigationController and window are initialized for you via the NIB). Now then, without adding any more code, there are already two things we would like to test:

• The UINavigationController's view is a sub-view of our window.
• The window is made 'key' and 'visible' on start.

Assumptions

Since we are not loading the actual NIB file, we need to set up the following assumptions.

• The reference to a UINavigationController instance variable is properly set.
• The reference to a UIWindow instance variable is set.

Making these assumptions means we will not be testing them directly, but it's a compromise which is better than not testing our delegate at all. Moreover, if either of these assumptions are ever invalidated, we can trust that the error will be easily noticeable upon application start up.

Test Setup

Here is the setUp method of my test class. Notice that my mock objects don't really come into play yet.

- (void) setUp {
	//
	// Create placeholder for controller
	//
	UINavigationController *nav;
	nav = [[UINavigationController alloc] init];
	nav.view = [[UIView alloc] init];

	//
	// Initialize delegate with placeholder
	//
	delegate = [[MyApplicationDelegate alloc] init];
	delegate.navigationController = nav;
}

The delegate is missing a reference to it's UIWindow. Rather than setting that dependency in the set up, I choose to add it in the test method below, grouped with expectations on the mock itself before invoking applicationDidFinishLaunching:.

The Unit Test

- (void) testDelegateInitializesWindowSubview {
	//
	// Mock window on our delegate
	//
	id mockWindow = [OCMockObject mockForClass:[UIWindow class]];
	delegate.window = mockWindow;

	//
	// Set up expectations
	//
	UIView *expectedView = delegate.navigationController.view;
	[[mockWindow expect] addSubview: expectedView];
	[[mockWindow expect] makeKeyAndVisible];

	//
	// Invoke & verify
	//
	id myApp = [OCMockObject mockForClass:[UIApplication class]];
	[delegate applicationDidFinishLaunching:myApp];
	[mockWindow verify];
}

Whether or not you set up the mock window object in the test method or setUp is up to you. I find it good practice to only put code in setUp that applies to all test methods. Since this is the only test method I expect will exercise the UIWindow dependency, I move it closer to the test case itself. To leave it in setUp may suggest to another developer that all test cases require this dependency to be set at all times. Because of the nature of the application delegate, however, that is likely not to be the case.

I hope this shows you a way in which you can test your delegate methods, and more importantly, dispel any notions that the delegate itself is too hard to test.

If you take a look at UIApplicationDelegate, you will quickly find that the methods here are not at all trivial, and relying on manual testing alone is risky. In this regard, I think using OCMock for this purpose is not only a smart move, but also necessary to avoid any collisions with the bootstrapping of your test environment itself.

software development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment