Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Sunday, January 10, 2010

Unit testing Core Data-driven apps, fit the second

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.

posted by Graham Lee at 18:12  

Sunday, September 6, 2009

Unit testing Core Data-driven apps

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

posted by Graham Lee at 15:36  

Wednesday, June 10, 2009

Unit testing Cocoa projects in Xcode

Unlike Bill, whose reference to unit testing in Xcode 3.0 is linked at the title, when I started writing unit tests for my Cocoa projects I had no experience of testing in any other environment (well, OK, I’d used OCUnit on GNUstep, but I decline to consider that as a separate environment). However, what I’ve seen of unit testing in Cocoa still makes me think I must be missing something.

The first thing is that when people such as Kent Beck talk about test-driven development, they mention “red-green-refactor”. Well, where’s my huge red bar? Actually, I sometimes write good code so I’d like to see my huge green bar too, but Xcode 3.1 doesn’t have one of those either. You have to grub through the build results window to see what happened.

Sometimes, a test is just so badly broken that rather than just failing, it crashes the test runner. This is a bit unfortunate, because it can be very hard to work out what test broke the harness. That’s especially true if the issue is some surprising concurrency bug and one test breaks a different test, or if the test manages to destroy the assumptions made in -teardown and crashes the harness after it’s run. Now Chris Hanson has posted a workaround to get the debugger working with a unit test bundle target, but wouldn’t it be nice if that “just worked”, in the same way that breaking into the debugger from Build and Run “just works” in an app target?

posted by Graham Lee at 16:52  

Powered by WordPress