Tips and Tutorials for using UISpec with API data

I need to start doing some TDD for this iPhone project. The issue is that it uses API data pretty 开发者_如何学Pythonheavily.

I'm looking for a good tutorial/guide/example project that shows how to implement TDD how to setup the database before each test is run for the iPhone. I'm leaning toward using UISpec but I'm willing to look into some other test suite if it does this better. Also the project already includes RestKit which uses UISpec for it's own testing, so UISpec is already included in the Xcode project.

---

I am the lead developer for the RestKit project and I would recommend that you not use UISpec for your testing. RestKit's use of UISpec (more accurately, a pared down highly customized version of it) is an artifact from early in the development -- I was using UISpec for functional testing and was hesitant to carry around so many libraries. These days UISpec is essentially abandonware and I have moved on to using KIF from Square for my UI/functional testing.

For unit testing on new projects, I like Kiwi (https://github.com/allending/Kiwi) as 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 solid as well. RestKit itself will likely transition off of UISpec at some point in the near future.

Now, on the question of how to setup the database for your tests. If you look in the RKSpecEnvironment.h/m files in RestKit, there are a bunch of helpful methods for unit testing. Assuming that you are using RestKit's Core Data integration, the RKSpecNewManagedObjectStore() method will tear down the Core Data environment and set you back up with a clear database by deleting the persistent store.

RestKit's own unit tests can provide some good reference (aside from the test harness concerns above) about how to unit against the API data. The RKSpecResponseLoader class is useful for turning asynchronous REST requests into procedural steps (it serves as a delegate for RKObjectLoader and will spin the run loop to wait for a request to load) that you can test against. So the general pattern is to clear the database state, setup any objects you need/expect, then perform an API interaction and assert against the results or new state in Core Data.