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?
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 methodexecuteRequest: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.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.