-
Get a monthly update on best practices for delivering successful software.

Testing your iPhone application, you may at some point in time need to stub a method call whose return type is a boolean (or some scalar value, or C based structure). The way to implement this (as described in a discussion on CocoaDev here) is to wrap the boolean in an NSValue using the OCMOCK_VALUE() macro defined in OCMockRecorder.h.
While this solution technically works, I find that doing this within the test class itself makes the test cases a little less readable along the way. Instead, I found it useful to extend OCMock to do this type of conversion for me, keeping my test code a bit cleaner as a result.
Let's take a look at an example by examining the set up for a simple test case..
Topics: iPhone, mock objects, obj-c, ocmock, Testing

Updated. (see comments below)
There may be cases where a certain setting needs to be tweaked based on whether you test on the device or simulator. It took me a while to find the pre-processor directive to detect whether or not the current build targets the iPhone device or the simulator, but with a bit of searching through the GTM code, I found everything I needed in "TargetConditionals.h". An obvious place, in retrospect, but I wasn't able to find this information easily elsewhere on the web, so I mention it here in case you find it useful.
Here's an example of how I've used it:
#if TARGET_CPU_ARM#if TARGET_IPHONE_SIMULATOR // Device will hit external server over cell network NSString const *ROOT_URL = @"http://www.external-site.com"; #else // Simulator will hit local server over LAN NSString const *ROOT_URL = @"http://localhost:8667"; #endif
This kind of tweaking is particularly important when the device itself can not participate on the local network, but needs to access some kind of external environment (or proxy server). Conversely, targeting the simulator to use a local 'development' server is often faster when deploying and debugging issues in your application, particularly if you are developing the server component in tandem.
Another example involved certain audio playback features which work fine on the device, but run into hiccups running on the simulator. Since in this case the functionality is not critical to test, I ignore it in the simulator.
Related Services: iPhone Application Development, Custom Software Development