iPhone SDK: Testing UIApplicationDelegate with OCMock

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:
- Initialize the view controller in your setup using
initWithNibName:bundle:. - Force the view to initialize by invoking the controller's
loadViewmethod within yoursetUpmethod. - 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
UINavigationControllerinstance variable is properly set. - The reference to a
UIWindowinstance 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.
Topics: iPhone, mock objects, ocmock, Testing
Leave a comment
About Pathfinder
Follow the Blog
-
Get a monthly update on best practices for delivering successful software.
Subscribe via email
Subscribe via RSS
Categories
Topics
Archives
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Blogroll
Recent
- Elements of Testing Style
- Aesthetics and Web Design
- Asterisk-Java Testing with Groovy
- 3 Misuses of Code Comments
- Fluently NHibernate
- Digging a Hole and Covering it with Leaves — The Software Development Version
- The Importance of User Experience - Do You Understand It in Your Bones?
- Writing Your Own Protocol With NSURLProtocol
- What’s In Your Dock: iPhone edition
- Feature Fatigue
