5

I have some Objective-C [i-os] code that I would like to run unit tests over using XCode. It accesses different metadata depending on the type of device, using:

[[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPad

The problem I have is that when I run the Unit Tests, this result is always true. Ideally, it would be great to be able to set it as the test runs.

The way I guess it could be done is by creating a class that encapsulates the device check and mock that for the test. But I thought it might be worth seeing if there are any better solutions.

For reference, a nice blog post with many links, the Apple Unit testing guide and Unit test sample code project.

lindon fox
  • 3,298
  • 3
  • 33
  • 59

1 Answers1

6

I tried a couple different approaches this morning:

  1. Using a UIDevice category that is only linked to my test target. In that category I would override currentDevice with a partialMock implementation (OCMock) and stub the necessary method so that it returns Pad or Phone forcedly to my specifics tests. It should have work, but its very difficult to mess with classes such as UIDevice or UIApplication, the simulator often crashes which is a bad sign.

  2. #undef UI_INTERFACE_IDIOM() and #define it on my test .pch. Pointing UI_INTERFACE_IDIOM() implementation in the test to a singleton instance of my own, that I could set to Pad or Phone accordingly. That worked, but the main problem is that when you run the tests the simulator also goes up ( application tests that is ) so if you are running your tests on the iPad, your test will pass, but other parts of the simulator will fail because of the contraditory responses it gets from UI_INTERFACE_IDIOM() (one of such is the loading of nib's specific to iPhone if you are in a universal app environment )

  3. I think this is the best approach. As everything in computer science, just put another layer in =) Instead of your code using UI_INTERFACE_IDIOM() to assess if it is on a Pad or Phone device, encapsulate this logic in a object that you can mock during your tests. That way UI_INTERFACE_IDIOM() will still be available to the rest of the simulator. Your production code will actually rely on it, but your tests will rely on a stubbed implementation that can respond as expected in your tests.

If you want to, I can share some codes regarding this matter. And yes, this is a weary one!

How you managed to workaround this?

lindon fox
  • 3,298
  • 3
  • 33
  • 59
Victor Lima
  • 136
  • 1
  • 4
  • Welcome to SO and nice first answer! +1. I am afraid I had given up on this one for the time being - automated testing is a dirty word in my workplace and I am more concerned with getting Source Control in place first. Having said that, I would like to get it going eventually and it seems that automated testing is much harder than it should be at the moment. Any additional details you could give would be appreciated. Thanks. – lindon fox Jul 02 '12 at 03:50
  • Whatever you do, dont give up!!! Maybe this will help: http://www.amazon.com/Test-Driven-iOS-Development-Developers-Library/dp/0321774183 – Victor Lima Jul 03 '12 at 01:26
  • Thanks for the link! I shall take a look. – lindon fox Jul 10 '12 at 01:02
  • Hi, do you know a way to do this and not lose out on iOS' ability to determine different XIB files say for a single viewcontroller in a universal app? (Using the MyView~iphone.xib/MyView~ipad.xib only requires to pass @"MyView" in the name of the xib file). You may have something enabled in iPhone version, but disabled in iPad version and I want to test that without reinventing the wheel so to speak. – LightningStryk Jan 10 '14 at 16:24