{"id":3467,"date":"2014-02-20T15:58:14","date_gmt":"2014-02-20T15:58:14","guid":{"rendered":"http:\/\/ushipblogsubd.wpengine.com\/?p=3467"},"modified":"2025-09-03T16:07:35","modified_gmt":"2025-09-03T16:07:35","slug":"unit-testing-around-singletons-with-ocmock","status":"publish","type":"post","link":"https:\/\/ushipblogsubd.wpengine.com\/shipping-code\/unit-testing-around-singletons-with-ocmock\/","title":{"rendered":"Unit Testing Around Singletons with OCMock"},"content":{"rendered":"

Whether you agree with the use of <\/span>singletons<\/a> or not, you can\u2019t completely avoid them as an iOS developer. Apple provides some critical functionality through singletons exposed in its iOS SDK, but it can be quite difficult to write unit tests around code that accesses them. In this article, I will describe a couple of techniques for managing this. First though, let\u2019s set up an example of the sort of problem I\u2019m talking about.<\/span><\/p>\n

Problem<\/h1>\n

Let\u2019s say we have an app which is set up to register itself for push notifications. We\u2019ve already written a simple proof-of-concept view controller with a switch for the user to enable or disable these notifications. The code is written and working well, but looks terrible.<\/p>\n

\u00a0\"\"<\/p>\n

I mean how is the user supposed to know what that switch does? \u00a0And is it bugging anyone else that the switch isn\u2019t even centered? Clearly, we should make this screen a bit more interesting and add some new features. Maybe a label\u2026 some more colors\u2026oh! how about some animation?<\/p>\n

Whatever we decide to do, we want to make sure we don\u2019t break the existing functionality. \u00a0The switch works, but there are no unit tests to verify that it does.<\/span><\/p>\n

Solution<\/span><\/strong><\/p>\n

While our designer figures out what features we want to add, let’s give this code some test coverage. \u00a0Let\u2019s start by taking a look at the code we\u2019re going to work with. \u00a0Here is the interface for the view controller.<\/p>\n

[cc lang=”objc”]
\n@interface SettingsViewController : UIViewController
\n{
\n@property (nonatomic, strong) IBOutlet UISwitch *pushNotificationsSwitch;
\n– (IBAction)pushNotificationsSwitchWasToggled:(id)sender;
\n}
\n[\/cc]<\/p>\n

…and here\u2019s the implementation.<\/span><\/p>\n

[cc lang=”objc”]
\n@implementation SettingsViewController<\/p>\n

– (void)viewDidLoad
\n{
\n\/\/create the switch
\nself.pushNotificationsSwitch = [[UISwitch alloc] initWithFrame:CGRectMake(0, 0, 50, 30)];<\/p>\n

\/\/link it to the action method
\n[self.pushNotificationsSwitch addTarget:self action:@selector(pushNotificationsSwitchWasToggled:) forControlEvents:UIControlEventValueChanged];
\n}<\/p>\n

– (IBAction)pushNotificationsSwitchWasToggled:(id)sender
\n{
\nUISwitch *toggleSwitch = sender;
\nif (toggleSwitch.on)
\n{
\n\/\/if the switch was toggled on, register for push notifications
\n[[UIApplication sharedApplication] registerForRemoteNotificationTypes:(UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeAlert)];
\n}
\nelse
\n{
\n\/\/if it was toggled off, unregister
\n[[UIApplication sharedApplication] unregisterForRemoteNotifications];
\n}
\n}
\n@end
\n[\/cc]<\/p>\n

We\u2019ll first try to write a test to verify that the app gets registered for push notifications when that lonely switch gets flipped to ON.<\/p>\n

[cc lang=”objc”]
\n– (void)testToggleOnRegistersForPushNotifications_On
\n{
\n\/\/given the view controller is loaded
\nSettingsViewController *sut = [[SettingsViewController alloc] init];
\n[sut view];<\/p>\n

\/\/given the switch is toggled on
\n[sut.pushNotificationsSwitch setOn:YES];<\/p>\n

\/\/when the view controller is notified that the switch was toggled
\n[sut pushNotificationsSwitchWasToggled:sut.pushNotificationsSwitch];<\/p>\n

\/\/then the app should register for notifications with alerts and badges
\n\/\/?? how do we verify this
\n}
\n[\/cc]<\/p>\n

Let\u2019s walk through what\u2019s going on here. \u00a0We create an instance of the SUT<\/a>, then simulate the act of flipping the switch to ON. Unfortunately, we\u2019re not sure now how to verify that the switch did what it\u2019s supposed to because all it does is call methods on the UIApplication<\/strong> singleton! To finish the test, we need to figure out a way to expose [UIApplication sharedApplication]<\/strong> as a dependency. One way to do that is through dependency injection<\/a>.<\/p>\n

With Dependency Injection<\/h1>\n

To use dependency injection, we\u2019ll have to modify our view controller class so we can provide an instance of UIApplication<\/strong> that it can work with. Then the app can use the real sharedApplication<\/strong> instance, while the test uses a mock object. \u00a0To accomplish this, we\u2019ll add a new property to the SettingsViewController<\/strong> interface…<\/p>\n

[cc lang=”objc”]
\n@property (nonatomic, strong) UIApplication *application;
\n[\/cc]<\/p>\n

…and modify our view controller implementation to use it.<\/span><\/p>\n

[cc lang=”objc”]
\n– (UIApplication*)application
\n{
\nif (!_application)
\n{
\n_application = [UIApplication sharedApplication];
\n}
\nreturn _application;
\n}<\/p>\n

– (IBAction)pushNotificationsSwitchWasToggled:(id)sender
\n{
\nUISwitch *toggleSwitch = sender;
\nif (toggleSwitch.on)
\n{
\n[self.application registerForRemoteNotificationTypes:(UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeAlert)];
\n}
\nelse
\n{
\n[self.application unregisterForRemoteNotifications];
\n[\/cc]<\/p>\n

The first method here is lazy-loading the application property so that it defaults to [UIApplication sharedApplication]<\/strong> when the app is running for real. \u00a0Then we changed pushNotificationsSwitchWasToggled:<\/strong> to refer to self.application<\/strong> instead of [UIApplication sharedApplication]<\/strong>.<\/p>\n

With that out of the way, we can finish our test by initializing the view controller with a mock object before the switch is toggled. The test can then monitor that mock to verify the behavior we\u2019re expecting. Here\u2019s our unit test again. This time, the test is using the mocking framework\u00a0OCMock<\/a> to create the mock, set up expectations, and verify them.<\/p>\n

[cc lang=”objc”]
\n– (void)testToggleOnRegistersForPushNotifications_On
\n{
\n\/\/given
\nid mockApplication = [OCMockObject niceMockForClass:[UIApplication class]];
\n[[mockApplication expect] registerForRemoteNotificationTypes:(UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeAlert)];<\/p>\n

SettingsViewController *sut = [[SettingsViewController alloc] init];
\nsut.application = mockApplication;
\n[sut view];
\n[sut.pushNotificationsSwitch setOn:YES];<\/p>\n

\/\/when
\n[sut pushNotificationsSwitchWasToggled:sut.pushNotificationsSwitch];<\/p>\n

\/\/then
\n[mockApplication verify];
\n}
\n[\/cc]<\/p>\n

Here our mock instance is configured to expect a message with the signature registerForRemoteNotificationTypes:<\/strong> and some very specific arguments. We then simulate flipping the switch to ON. At the end of the test, we ask the mock to verify that the expected method was actually called. If not, the test raises an exception on that last line and the test is reported as a failure.<\/p>\n

You\u2019ll notice that to use dependency injection, we had to modify a lot of our app\u2019s code to make it testable. \u00a0Imagine SettingsViewController<\/strong> was a much larger and more complicated class without any unit test coverage. It could be quite intimidating to have to change that code just to make it testable. You could break it just trying to test it. If for some reason you can\u2019t or don\u2019t want to take that risk, there\u2019s another way to test this code.<\/p>\n

Without Dependency Injection<\/h1>\n

In the case of our SettingsViewController<\/strong>, we can actually stub out this singleton dependency without resorting to dependency injection. OCMock<\/a> in particular is actually quite helpful in this case. With the help of OCMock, we can temporarily replace the singleton instance with a mock object that can be monitored by our test.<\/p>\n

Here\u2019s that same test again, but this time, we\u2019ll do our mocking without<\/em> dependency injection.<\/p>\n

[cc lang=”objc”]
\n– (void)testToggleOnRegistersForPushNotifications_On
\n{
\n\/\/given a mock UIApplication
\nid mockApplication = [OCMockObject niceMockForClass:[UIApplication class]];
\n[[[mockApplication stub] andReturn:mockApplication] sharedApplication];
\n[[mockApplication expect] registerForRemoteNotificationTypes:(UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeAlert)];<\/p>\n

\/\/given the view controller is loaded
\nSettingsViewController *sut = [[SettingsViewController alloc] init];
\n[sut view];<\/p>\n

\/\/given the switch is toggled on
\n[sut.pushNotificationsSwitch setOn:YES];<\/p>\n

\/\/when the view controller is notified that the switch was toggled
\n[sut pushNotificationsSwitchWasToggled:sut.pushNotificationsSwitch];<\/p>\n

\/\/then the app should register for notifications with alerts and badges
\n[mockApplication verify];<\/p>\n

\/\/finally clean up the mock (VERY IMPORTANT)
\n[mockApplication stopMocking];
\n}
\n[\/cc]<\/p>\n

Here we simply stub out the singleton accessor method and force it to return our mock object. Now, whenever any code in the app calls [UIApplication sharedApplication]<\/strong>, it will actually get this instance of OCMockObject<\/strong> instead.<\/p>\n

You may have noticed that the first time we wrote this test we didn\u2019t call stopMocking<\/strong> at the end. Normally, at the end of a test, you don\u2019t have to worry about cleaning up a mock instance like this. A normal mock just evaporates as soon as it falls out of scope. But not this one. Since we\u2019re mocking a singleton, the instance won\u2019t actually fall out of scope after the test.<\/p>\n

Try this to see what I mean. Comment out the stopMocking<\/strong> line in the test above and add this test at the end of the same test suite:<\/p>\n

[cc lang=”objc”]
\n– (void)testZ_MockWasActuallyDestroyed
\n{
\nid app = [UIApplication sharedApplication];
\nXCTAssert([app isMemberOfClass:[UIApplication class]],
\n@”a mock for UIApplication sharedApplication was not cleaned up!”);
\n}
\n[\/cc]<\/p>\n

The \u2018Z\u2019 at the front of the test name just forces it to run last. This is because OCUnit\/XCUnit tests run in alphabetical order. \u00a0With the call to stopMocking<\/strong> commented out, you\u2019ll see that this new test fails.<\/p>\n

So it\u2019s VERY IMPORTANT that you call OCMock\u2019s stopMocking<\/strong> method on the mock singleton object when you\u2019re done with it. Forgetting this step means your mock singleton instance will survive and potentially influence the outcome of other unit tests.<\/p>\n

You can find a sample project on github<\/a> which shows all the code above in action. \u00a0It also includes some alternate unit tests which demonstrate doing some of the same things using Jon Reid’s OCMockito<\/a>, instead of OCMock.<\/p>\n

[amp-cta id=’8486′]<\/p>\n","protected":false},"excerpt":{"rendered":"

Whether you agree with the use of singletons or not, you can\u2019t completely avoid them as an iOS developer. Apple provides some critical functionality through singletons exposed in its iOS SDK, but it can be quite difficult to write unit tests around code that accesses them. In this article, I will describe a couple of… Read More<\/a><\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[295,2],"tags":[15,16,17,297,19],"class_list":["post-3467","post","type-post","status-publish","format-standard","hentry","category-shipping-code","category-company-news","tag-ios-developer","tag-native-mobile-app","tag-ocmock","tag-shipping-code","tag-unit-testing"],"acf":{"blog_post_content":[{"acf_fc_layout":"blog_post_entry_footer","blog_post_entry_footer_cta":[{"blog_post_entry_footer_cta_url":"https:\/\/www.uship.com\/","blog_post_entry_footer_cta_text":"Ready to Ship Something?","blog_post_entry_footer_onclick":""}]}]},"_links":{"self":[{"href":"https:\/\/ushipblogsubd.wpengine.com\/wp-json\/wp\/v2\/posts\/3467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ushipblogsubd.wpengine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ushipblogsubd.wpengine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ushipblogsubd.wpengine.com\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/ushipblogsubd.wpengine.com\/wp-json\/wp\/v2\/comments?post=3467"}],"version-history":[{"count":0,"href":"https:\/\/ushipblogsubd.wpengine.com\/wp-json\/wp\/v2\/posts\/3467\/revisions"}],"wp:attachment":[{"href":"https:\/\/ushipblogsubd.wpengine.com\/wp-json\/wp\/v2\/media?parent=3467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ushipblogsubd.wpengine.com\/wp-json\/wp\/v2\/categories?post=3467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ushipblogsubd.wpengine.com\/wp-json\/wp\/v2\/tags?post=3467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}