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

Imagine that we have a class (‘MyTreeNode‘), which models a typical tree-like structure. Each node in the tree must respond to the selector ‘hasChildren‘, which returns a boolean of type BOOL.

Initial Testcase

BOOL yes = YES;
NSValue *wrappedValue = [NSValue valueWithBytes:&yes
                                       objCType:@encode(BOOL)];

id mockRoot = [OCMockObject mockForClass:[MyTreeNode class]];
[[[mockRoot stub] andReturnValue:wrappedValue] hasChildren];

(Note that I am using valueWithBytes:objCType: on NSValue instead of value:objCType:, as found in the OCMOCK_VALUE macro. It’s a slight difference, but since the API docs for NSValue suggest that the latter may deprecated at a future date, I would use the preferred method call instead).

This test case is all fine and good, but those top two lines have nothing to do with expressing the real intent of this test case. In the end, it’s all just noise. Improving on this, you can encapsulate the creation and use of the NSValue behind the mocking framework. This is accomplished using a simple category.

Extending OCMock

The interface is defined as follows, in a file I named “OCMockExtensions.h”:

#import <OCMock/OCMock.h>

@interface OCMockRecorder (BooleanMethods)
- (id) andReturnBoolean:(BOOL)aValue;
@end

The implementation itself is also straightforward. We basically implement the same logic, but hide it behind a new method on OCMockRecorder itself.

@implementation OCMockRecorder (BooleanMethods)

- (id) andReturnBoolean:(BOOL)aValue {
    NSValue *wrappedValue = nil;
    wrappedValue = [NSValue valueWithBytes:&aValue
                                  objCType:@encode(BOOL)];

    return [self andReturnValue:wrappedValue];
}

@end

Resulting Testcase

All of this allows us to stub out our hasChildren method in the original test case using a more readable form.

  id mockRoot = [OCMockObject mockForClass:[MyTreeNode class]];
  [[[mockRoot stub] andReturnBoolean:YES] hasChildren];

Short and sweet. There are probably other variations on this theme, each of which might make more sense for you. But I hope this gets you thinking of how best to handle these types of test scenarios without having to clutter your test method with a lot of set up code for your mocks. If experience is any guide, set up code for mock objects can easily get out of hand as a code base matures, so anything you can do to reduce this clutter and help the test cases express their intent in a clear and succinct manner can go a long way toward having your tests work for your team.

Related Services: iPhone Application Development, Custom Software Development

Share/Bookmark