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.
I tried a couple different approaches this morning:
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.
#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 )
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?