Topic: obj-c

OCMock: Handling Boolean Return Types with NSValue

iPhone in Dock

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..

Continue reading »

iPhone: Using Pre-processor Directives for Device Testing

iPhone in Dock
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

Topics: , ,

Launch: Pathfinder Newsletter

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

    Subscribe via email


    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com