Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Core Data Unit Testing - Unsure how to trigger error case in executeFetchRequest:error:

According to NSManagedObjectContext Class Documentation...

- (NSArray *)executeFetchRequest:(NSFetchRequest *)request error:(NSError **)error

Return Value

An array of objects that meet the criteria specified by request fetched from the receiver and from the persistent stores associated with the receiver’s persistent store coordinator. If an error occurs, returns nil. If no objects match the criteria specified by request, returns an empty array.

I'm trying to create a unit test for the situation "if an error occurs, returns nil."

I would like to stay away from using OCMock (or subclassing NSManagedObjectContext to override the executeFetchRequest:error: method) because I figure there's an easy way to ensure failure of this method. So far my unit test reads...

- (void)testReportingCoreDataErrorToDelegate
{
    NSManagedObjectContext *badContext = [[NSManagedObjectContext alloc] init];

    [bcc setManagedObjectContext:badContext];
    [bcc fetchFromCoreData];
    STAssertTrue([mockDelegate didReceiveCoreDataError], @"This never asserts, it fails because the fetch request couldn't find an entity name - i.e. no managed object model");
}

Is there a simple way to trigger a fetch request returning nil?

like image 640
edelaney05 Avatar asked Oct 08 '22 14:10

edelaney05


1 Answers

I had the same conundrum. I like to keep unit test coverage at 100% whenever possible. There is no easy way to generate an organic error condition. In fact, I'm not sure the current implementation of the 4 store types that come with Core Data will ever trigger an error in response to executeFetchRequest:error. But as it could happen in the future, here is what I did:

I have one unit test case file that is dedicated to validating how my classes handle errors populated by executeFetchRequest:error. I define a subclass of NSIncrementalStore that always produces an error during requests in the implementation file. [NSManagedObjectContext executeFetchRequest:error] is processed by [NSPersistentStoreCoordinator executeRequest:withContext:error:] which processes [NSPersistentStore executeRequest:withContext:error:] on all stores. You may notice that the word "fetch" drops when you move to the coordinator - saves and fetch requests are handled by the same method executeRequest:withContext:error:. So I get coverage for testing against save errors and fetch requests by defining a NSPersistentStore that will always respond to saves and fetches with errors.

#define kErrorProneStore @"ErrorProneStore"
@interface ErrorProneStore : NSIncrementalStore


@end

@implementation ErrorProneStore

- (BOOL)loadMetadata:(NSError **)error
{
    //Required - Apple's documentation claims you can omit setting this, but I had memory allocation issues without it. 
    NSDictionary * metaData = @{NSStoreTypeKey : kErrorProneStore, NSStoreUUIDKey : @""};
    [self setMetadata:metaData];
    return YES;
}
-(void)populateError:(NSError **)error
{
    if (error != NULL)
    {
        *error = [[NSError alloc] initWithDomain:NSCocoaErrorDomain
                                            code:NSPersistentStoreOperationError
                                        userInfo:nil];
    }
}
- (id)executeRequest:(NSPersistentStoreRequest *)request
         withContext:(NSManagedObjectContext *)context
               error:(NSError **)error
{
    [self populateError:error];
    return nil;
}
- (NSIncrementalStoreNode *)newValuesForObjectWithID:(NSManagedObjectID *)objectID
                                         withContext:(NSManagedObjectContext *)context
                                               error:(NSError **)error
{
    [self populateError:error];
    return nil;
}
- (id)newValueForRelationship:(NSRelationshipDescription *)relationship
              forObjectWithID:(NSManagedObjectID *)objectID
                  withContext:(NSManagedObjectContext *)context
                        error:(NSError **)error
{
    [self populateError:error];
    return nil;
}
- (NSArray *)obtainPermanentIDsForObjects:(NSArray *)array
                                    error:(NSError **)error
{
    [self populateError:error];
    return nil;
}
@end

Now you can construct the Core Data stack using the ErrorProneStore and be guaranteed your fetch requests will return nil and populate the error parameter.

- (void)testFetchRequestErrorHandling
{
    NSManagedObjectModel * model = [NSManagedObjectModel mergedModelFromBundles:nil];

    [NSPersistentStoreCoordinator registerStoreClass:[ErrorProneStore class]
                                        forStoreType:kErrorProneStore];

    NSPersistentStoreCoordinator * coordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:model];


    NSManagedObjectContext * context = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
    [context setPersistentStoreCoordinator:coordinator];
    [coordinator addPersistentStoreWithType:kErrorProneStore
                              configuration:nil
                                        URL:nil
                                    options:nil
                                      error:nil];

    NSFetchRequest * request = [NSFetchRequest fetchRequestWithEntityName:@"AValidEntity"];

    NSError * error;
    [context executeFetchRequest:request
                           error:&error];

    STAssertNotNil(error, @"Error should always be nil");
}
like image 178
Fruity Geek Avatar answered Oct 12 '22 10:10

Fruity Geek