I am the lead developer of the RestKit project, and I would recommend that you use non- UISpec for testing. Using RestKit UISpec (more precisely, an abridged version with high customization) is an artifact from the very beginning of development - I used UISpec for functional testing and did not dare to transfer so many libraries. UISpec is essentially a failure these days, and I switched to using KIF from Square for my user interface / functional testing.
For unit testing new projects, I like Kiwi ( https://github.com/allending/Kiwi ) because it sits on top of the built-in SenTestingKit and provides RSpec-style tests. Cedar ( https://github.com/pivotal/cedar ) from Pivotal Labs and GHUnit ( http://gabriel.github.com/gh-unit/ ) are also solid. RestKit itself is likely to move to UISpec in the near future.
Now about how to set up a database for your tests. If you look in the RKSpecEnvironment.h / m files in RestKit, there are many useful methods for unit testing. Assuming you are using integration with RestKit Core databases, the RKSpecNewManagedObjectStore () method will destroy the Core Data environment and set up backups using a clean database, removing persistent storage.
RestKit's own unit tests can provide some good reference (besides the above testing issues) about how to block API data. The RKSpecResponseLoader class is useful for turning asynchronous REST requests into procedural steps (it serves as a delegate for RKObjectLoader and will rotate the loop to wait for the request to load) with which you can test. Thus, the general template is to clear the state of the database, configure any objects that you need / expect, and then interact with the API and approve against the results or the new state in Core Data.
source share