Unit Testing - Core Data - page 180

Note: To round out this test case in a real development context, you would
want to write unit tests for strange scenarios like nil or empty parameters,
duplicate camper names and so forth.
Run the unit tests by clicking on the Product menu, then selecting Test (or type
Command+U ). You should see a green checkmark in Xcode:
There's your first test! You can imagine this kind of testing is useful for your data
models, checking that the attributes were stored correctly.
Also notice how it acts like documentation for people using the API; it's an example
of how to call addCamper and describes the expected behavior, for example that the
method should return a valid object and not nil.
Notice this test creates the object and checks the attributes, but doesn't save
anything to the store. This project uses a separate queue context, allowing it to
perform saves in the background. However, the test runs straight through so you
can't check for the save result with an XCTAssert since you can't be sure when the
background operation has completed. Of course saving is an important part of Core
Data, so how can you test this part of the app?
Asynchronous tests
When using a single managed object context in Core Data, everything runs on the
main UI thread. However, this project has a separate private queue context which
acts as the root context, allowing saving to be performed on a background thread.
The main context exposed by the Core Data stack is a child of this context.
Performing work on the right thread for a context is easy: You simply wrap the
work in performBlockAndWait() or performBlock() to ensure it's executed on the
proper thread associated with the context. The former will wait to finish execution
of the block before continuing, and the latter will immediately return, queuing the
execution on the context.