I'm looking for suggestions on best practices for CoreData testing. I've been using the incremental UUID system for most of my testing so far and it's worked for what I needed. I'm at a point now where I'm testing state that holds newly created CoreData objects. The problem is the ObjectID and all child ObjectIDs which I have no control over and assertions fail. Has anyone found a reasonable solution for testing CoreData objects and state? At one point I considered having my persistence layer convert all CoreData objects into struct versions but I'm trying to avoid it if possible due to time and maintenance.
FWIW, we created 'proxy' objects for our CoreData entities. Our app works only with these proxies, and in our environment object we have our 'DataClient' that can mutate the DB given these proxies.
Interesting. I figured that would end up being the solution. Do your proxy objects automatically pull the whole record and associated children eagerly?
Yeah, right now, we load up the full initial app state as a collection of proxies. For object references, we create proxies for those too, but that's a little more than we like, so we're going to back off a bit and keep only reference id's. Note that we don't use CoreData id's, we use our own unique id for each of the proxy objects.
For persistence, we have a reducer that maps proxy changes to coredata updates. I'm trying to come up with a more generic way of doing that, but baby steps.
BTW, to know when state additions and deletions have occurred, I'm using difference(from:) on my IndentifiedArray of proxy objects. It's a nice way to see what's been updated, added, and deleted.
Next up for us is to more lazily load data, but our data set isn't so big that we can't load it all in.
I'm not sure it will help since you seem to use the core data objects directly, but that's exactly what I try to run away from.
I only use CoreData (or any other db framework for that matter) to persist and load, after that I map directly to structs and deal with that on the rest of the app. I think this is the most sensible approach, otherwise you have managed objects everywhere that perform side effects without you being able to control them.
Thanks Alejandro. I think that's the path I'm going to take, it's a situation of time mainly. I'm working on this on the side and anything that takes up a large amount of dev time on creating or maintaining can take what would normally be a one to 2 day task at work and turn it into a 2 week task when I only get 15 minutes here and there. I was hoping someone had a piece of knowledge for equality comparison (other than ignoring the objectID) that I was unaware of to keep me from needing to maintain 2 sets of objects.