CoreData - Unit Test

I've got a simple employee manager which basically just creates a simple view context 

this is the main view context which for 99 % of all cases when you're building apps with core data this is goint to be fine 

this is the main thread that we're working against with core data 

everything's going to be read and written to it. 

 

so this manager simply

creates employees 

fetches employees

updates and deletes as your typical CRUD applications.

 

(SimpleEmployeeManager)

this is what we want to unit test our manager we want to make sure it works 

 

watch what happens if we naively come over here (unitTest) 

and set up a unit test and start wrting some tests to create employees, update employees and delete them 

 

when we hit command u and we go run the tests run and boom we get some failures. 

 

we can create employee okay, 

but updating doesn't work if we create an employee named jon and change his name to jonathan

he still finds jon when he shouldn't be there 

 

and when we go to delete and read

even though we've created three employees deleted one and we're expecting two 

we get back three

like what gives and if we run these unit tests again

we'll see that these numbers change now we're getting seven employees if i run them again now we're getting 11.

 

so this is naive way of writing unit tests and core data 

and what actually is going on here is this.

 

our app and our unit tests are sharing the same main context which core data uses to save all of its users and all of its data on disk. 

 

this is a collision of data we can't just user the same context over and over again we're goint to be overwriting each other it's goint to be very confusing. 

 

so that's the first problem , that's the challenge we run into if we naively go in there and start writing unit tests against our core data instance

 

 

okay now i know what you're thinking 

jonathan how do we fix this,? 

no problem i've got you. 

 

what we can do here is instead of having just one core data instance 

we can break it into two

 

 

we can create a core data stack which we use only in our application so all reads and writes go against this one(disk) 

and then for our init test we create a separate view context this one's going to be in memory it's going to be much faster and much better for unit testing and this is the one that we use for unit tests

 

so in code that looks like this.  

 

if we go over to our app 

first we're going to create a core data stack 

and what this thing is going to do is

 

it's going to set up our persistent container in a main context which is the one we're just goint to use 

to read and write to 

 

and it's just going to create this object for us 

and we're going to pass that into our medium employee manager because we're getting a little bit more complex now

 

but it's not that complex we're just passing in this main context on the initializer. 

 

so when our app runs now it's going to have it's main context that it can work against.

 

but when we go to the unit test 

 

we're going to have the exact same thing 

only this stack is just for the unit tests.

 

it's just going to use the same data model , it's going to load it up , but this time it's going to set it up in memory, which is way better way faster we don't want to write to disk when wh're writing unit tests. it's way too slow.

 

d

and we can make use of that in our medium employee manager test 

so we create that stack 

we pass it into our employee manager and boom now weve got this beautiful world of separate stacks we can run these things over and over again and this works just like butter this is great. 

 

now i know what you're thinking jonathan i heard it was good to set up actually multiple stacks in your application

 

in rare instances when you've got to do some really heavy core data lifting 

it's good to have a main view context for reads 

and a background thread context for writes 

and you'd be absolutely right 

 

in rare circumstances you can set both of these up so how do you handle that from unit tests ? 

no problem all we do here is create a main and background context set those up in our core data stacks for our app 

and for our unit test and then use those

여기부턴, 쓸일이 딱히 없기 때문에 포스팅을 마침. 

 

 

 

출처: https://www.youtube.com/watch?v=DTz_MFxe9mk