iamleeg

There are few people who can say that when it comes to Cocoa application security, they wrote the book. In fact, I can think of only one: me. I've just put the final draft together for Professional Cocoa Application Security and it will hit the shops in June: click the link to purchase through my Amazon affiliate programme.

Now that the book's more-or-less complete, I can turn my attention to other interesting projects: by which I mean yours! If your application could benefit from a developer with plenty of security experience and knowledge to share in a pragmatic fashion, or a software engineer who led development of a complex Cocoa application from its legacy PowerPlant origins through Snow Leopard readiness, or a programmer who has worked on performance enhancement in networking systems and low-level daemon code on Darwin and other UNIX platforms, then your project will benefit from an infusion of the Graham Lee magic. Even if you have some NeXTSTEP or OPENSTEP code that needs maintaining, I can help you out: I've been using Cocoa for about as long as Apple has.

Send an email to iamleeg <at> securemacprogramming <dot> com and let's talk about your project. The good news is that for the moment I am available, you probably can afford me[*], and I really want to help make your product better. Want to find out more about my expertise? Check out my section on the MDN show, and the MDN security column.

[*] It came up at NSConference that a number of devs thought I carry a premium due to the conference appearances, podcasts and other material I produce. Because I believe that honesty is the best policy, I want to come out and say that I don't charge any such premium. My rates are consistent with other contractors with my level of experience, and I even provide a discounted rate for NGOs and academic institutions.

It took longer than I expected to follow up my previous article on unit testing and Core Data, but here it is.

Note that the pattern presented last time, Remove the Core Data Dependence, is by far my preferred option. If a part of your code doesn't really depend on managed objects and suchlike, it shouldn't need them to be present just because it works with (or in) classes that do. The following pattern is recommended only when you aren't able to abstract away the Core Data-ness of the code under test.

Pattern 2: construct an in-memory Core Data stack. The unit test classes you develop ought to have these, seemingly contradictory properties:

• no dependence on external state: the tests must run the same way every time they run. That means that the environment for each test must be controlled exactly; dependence on "live" application support files, document files or the user defaults are all no-nos.


• close approximation to the application environment: you're interested in how your app runs, not how nice a unit test suite you can create.

To satisfy both of these properties simultaneously, construct a Core Data stack in the test suite which behaves in the same way but which does not use the persistent store (i.e. document files) used by the real app. My preference is to use the in-memory store type, so that every time it is created it is guaranteed to have no reference to any prior state (unlike a file-backed store type, where you have to rely on unlinking the document files and hoping there are no timing issues in the test framework which might cause two tests simultaneously to use the same file).

My test case class interface looks like this (note that this is for a dependent test case bundle that gets embedded into the app; there's an important reason for that which I'll come to later). The managed object context will be needed in the test methods to insert new objects, I don't (yet) need any of the other objects to be visible inside the tests but the same objects must be used in -setUp and -tearDown.

#import <SenTestingKit/SenTestingKit.h>

@interface SomeCoreDataTests : SenTestCase {
 NSPersistentStoreCoordinator *coord;
 NSManagedObjectContext *ctx;
 NSManagedObjectModel *model;
 NSPersistentStore *store;
}

@end

The environment for the tests is configured thus. I would have all of the error reporting done in tests, rather than that one lone assertion in -tearDown, because the SenTest framework doesn't report properly on assertion failures in that method or in -setUp. So the -testThatEnvironmentWorks test method is a bellwether for the test environment being properly set up, but obviously can't test the results of tear-down because the environment hasn't been torn down when it runs.

#import "TuneNeedsHighlightingTests.h"

@implementation TuneNeedsHighlightingTests

- (void)setUp
{
 model = [[NSManagedObjectModel mergedModelFromBundles: nil] retain];
 NSLog(@"model: %@", model);
 coord = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel: model];
 store = [coord addPersistentStoreWithType: NSInMemoryStoreType
 configuration: nil
 URL: nil
 options: nil 
 error: NULL];
 ctx = [[NSManagedObjectContext alloc] init];
 [ctx setPersistentStoreCoordinator: coord];
}

- (void)tearDown
{
 [ctx release];
 ctx = nil;
 NSError *error = nil;
 STAssertTrue([coord removePersistentStore: store error: &error], 
 @"couldn't remove persistent store: %@", error);
 store = nil;
 [coord release];
 coord = nil;
 [model release];
 model = nil;
}

- (void)testThatEnvironmentWorks
{
 STAssertNotNil(store, @"no persistent store");
}
@end

The important part is in setting up the managed object model. In using [NSManagedObjectModel mergedModelFromBundles: nil], we get the managed object model derived from loading all MOMs in the main bundle—remembering that this is an injected test framework, that's the application bundle. In other words the MOM is the same as that created by the app delegate. We get to use the in-memory store as a clean slate every time through, but otherwise the entity definitions and behaviours ought to be identical to those provided by the real app.

Needless to say, I'm standing on the shoulders of giants here. Chris Hanson has written a great post on setting up the Core Data "stack" inside unit tests, Bill Bumgarner has written about their experiences unit-testing Core Data itself and PlayTank have an article about introspecting the object tree in a managed object model. I'm not going to rehash any of that, though I will touch on bits and pieces.

In this post, I'm going to look at one of the patterns I've employed to create testable code in a Core Data application. I'm pretty sure that none of these patterns I'll be discussing is novel, however this series has the usual dual-purpose intention of maybe helping out other developers hoping to improve the coverage of the unit tests in their Core Data apps, and certainly helping me out later when I've forgotten what I did and why ;-).

Pattern 1: remove the Core Data dependence. Taking the usual example of a Human Resources application, the code which determines the highest salary in any department cares about employees and their salaries. It does not care about NSManagedObject instances and their values for keys. So stop referring to them! Assuming the following initial, hypothetical code:

- (NSInteger)highestSalaryOfEmployees: (NSSet *)employees {
	NSInteger highestSalary = -1;
	for (NSManagedObject *employee in employees) {
		NSInteger thisSalary = [[employee valueForKey: @"salary"] integerValue];
		if (thisSalary > highestSalary) highestSalary = thisSalary;
	}
	//note that if the set's empty, I'll return -1
	return highestSalary;
}

This is how this pattern works:

1. Create NSManagedObject subclasses for the entities.
   

   @interface GLEmployee : NSManagedObject
   {}
   @property (nonatomic, retain) NSString *name;
   @property (nonatomic, retain) NSNumber *salary;
   @property (nonatomic, retain) GLDepartment *department;
   @end
   

   
   This step allows us to see that employees are objects (well, they are in many companies anyway) with a set of attributes. Additionally it allows us to use the compile-time checking for properties with the dot syntax, which isn't available in KVC where we can use any old nonsense as they key name. So go ahead and do that!
   

   - (NSInteger)highestSalaryOfEmployees: (NSSet *)employees {
   	NSInteger highestSalary = -1;
   	for (GLEmployee *employee in employees) {
   		NSInteger thisSalary = [employee.salary integerValue];
   		if (thisSalary > highestSalary) highestSalary = thisSalary;
   	}
   	//note that if the set's empty, I'll return -1
   	return highestSalary;
   }
   

   
   


2. Abstract out the interface to a protocol.
   

   @protocol GLEmployeeInterface <NSObject>
   @property (nonatomic, retain) NSNumber *salary;
   @end
   

   
   Note that I've only added the salary to the protocol definition, as that's the only property used by the code under test and the principle of YAGNI tells us not to add the other properties (yet). The protocol extends the NSObject protocol as a safety measure; lots of code expects objects which are subclasses of NSObject or adopt the protocol. And the corresponding change to the class definition:
   

   @interface GLEmployee : NSManagedObject <GLEmployeeInterface>
   {}
   ...
   @end
   

   
   Now our code can depend on that interface instead of a particular class:
   

   - (NSInteger)highestSalaryOfEmployees: (NSSet *)employees {
   	NSInteger highestSalary = -1;
   	for (id <GLEmployeeInterface> employee in employees) {
   		NSInteger thisSalary = [employee.salary integerValue];
   		if (thisSalary > highestSalary) highestSalary = thisSalary;
   	}
   	//note that if the set's empty, I'll return -1
   	return highestSalary;
   }
   

   
   


3. Create a non-Core Data "mock" employee
   Again, YAGNI tells us not to add anything which isn't going to be used.
   

   @interface GLMockEmployee : NSObject <GLEmployeeInterface>
   {
   	NSNumber *salary;
   }
   @property (nonatomic, retain) NSNumber *salary;
   @end
   
   @implementation MockEmployee
   @synthesize salary;
   @end
   

   
   Note that because I refactored the code under test to handle classes which conform to the GLEmployeeInterface protocol rather than any particular class, this mock employee object is just as good as the Core Data entity as far as that method is concerned, so you can write tests using that mock class without needing to rely on a Core Data stack in the test driver. You've also separated the logic ("I want to know what the highest salary is") from the implementation of the model (Core Data).
   

OK, so now that you've written a bunch of tests to exercise that logic, it's time to safely refactor that for(in) loop to an exciting block implementation :-).