Testing iOS application modules using master data and magic recording

Question

I have an iOS app that uses Core Data along with a great Magical Record to manage storage. Here is my problem:

Our existing Unit Testing framework uses standard iOS application benchmarks. I want to run my unit tests with a clean in-memory db for each test. I followed the instructions in this article to install this using Magical Record. The problem occurs when running application tests. Since application tests first run the application package and then the unit test suite, my usual call to set up the underlying data stack is called before I have a call to store in memory.

I searched this issue all night and found a couple of promising articles:

• http://blog.goosoftware.co.uk//2013/02/07/unit-testing-a-coredata-manager-class/
• How to use basic data for dependency injection

The problem is that they use a one-way data access object as a gateway to their main data calls. My application is not configured this way. I use calls in Magical Record to retrieve and save data.

Has anyone encountered this problem? If so, are there some missing details that would allow me to change my data settings to storage in memory when performing my tests?

EDIT: Adding Code

In my application delegate, I have the following:

-(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{ [MagicalRecord setupAutoMigratingCoreDataStack]; // Other setup code return YES; } 

In every unit test class that deals with master data, I have this:

 -(void)setUp{ [super setUp]; [MagicalRecord setDefaultModelFromClass:[self class]]; [MagicalRecord setupCoreDataStackWithInMemoryStore]; } -(void)tearDown{ [MagicalRecord cleanUp]; [super tearDown]; } 

I see that for each test, both the delegation code of the application and the setup / shutdown are called, but I'm not sure how to make the default master data stack for tests using memory in memory. I also have a .xcdatamodel file added to the unit test target.

Answer 1

If I understand your problem correctly, the problem is that even after calling [MagicalRecord setupCoreDataStackWithInMemoryStore]; in setUp tests access a real data store?

I had the same problem when writing unit tests for objects responsible for interacting with the database, and with a little debugging, I think I found a problem.

[MagicalRecord setupAutoMigratingCoreDataStack]; c - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions called earlier [MagicalRecord setupCoreDataStackWithInMemoryStore]; in setUp . And if we look at how the main data stack works with MagicalRecord, we’ll understand what the problem is.

 + (void) setupCoreDataStackWithInMemoryStore; { if ([NSPersistentStoreCoordinator MR_defaultStoreCoordinator] != nil) return; NSPersistentStoreCoordinator *coordinator = [NSPersistentStoreCoordinator MR_coordinatorWithInMemoryStore]; [NSPersistentStoreCoordinator MR_setDefaultStoreCoordinator:coordinator]; [NSManagedObjectContext MR_initializeDefaultContextWithCoordinator:coordinator]; } 

[NSPersistentStoreCoordinator MR_defaultStoreCoordinator] non-zero at the storage setup point in memory and does the method above to silently return without any action. And at this moment you are left with your real data store instead of the storage in memory. The solution is simple. Just call

 [MagicalRecord cleanUp]; 

before calling [MagicalRecord setupCoreDataStackWithInMemoryStore]; in setUp to break the current data stack and really set up the storage in memory so it looks like this:

 - (void)setUp{ [super setUp]; [MagicalRecord setDefaultModelFromClass:[self class]]; [MagicalRecord cleanUp]; [MagicalRecord setupCoreDataStackWithInMemoryStore]; }