Adam Milligan's blog
If you're interested in following the growth of Cedar, or just testing iPhone projects in general, you can join the public Cedar discussion group or follow Cedar on Twitter at @cedarbdd.
I'll continue to write out my thoughts on the topic here, but I'd prefer to have a method of sharing information that anyone can post to.
For anyone following the Cedar project on GitHub, I've moved it from my personal GitHub account to Pivotal's GitHub account. This isn't a fork, it's a new repository that from here on out I'll use as the main Cedar repository.
If you're following Cedar, please follow the repo on the Pivotal account. If you've forked it please re-fork from the repo on the Pivotal account.
After enough time passes I'll probably delete the repo on my account and recreate it as a fork of the Pivotal repo. Sorry for the inconvenience.
When I started writing Objective-C for iPhone and iPad projects I started to hear about these mystical and all-powerful run loops objects. Everything seems to relate to run loops, all the class references talk about how one object or another depends on run loops, the most basic iPhone application documentation even talks about how the device starts and maintains the main run loop for you because it's so important. However, I found few straightforward descriptions of what a run loop is or how it works.
So, I read Apple's Threading Programming Guide. I read about timers and ports and sources, about the starting and stopping and timing out of run loops. After this reading, and a bit of thought, I realized that all the sound and fury surrounding run loops blinded me to the fact that they are actually very, very simple. To wit, run loops are a mechanism for single-threaded asynchronous programming. Sound familiar? Sounds to me a lot like JavaScript.
A little while ago I wrote about Cedar, a BDD-style testing framework for Objective-C. The responses I received nearly all went something along these lines: "That's great! Too bad I can't use it, since I'm writing an iPhone app."
Hogwash.
I actually wrote Cedar specifically for testing iPhone OS projects we're working on at Pivotal. To prove it, I've started a small public iPhone project that I've test-driven entirely with Cedar. You can get the project here (more on that in a bit); it should eventually allow you to log into Pivotal Tracker, see all the delivered stories in a given project, and accept or reject each one. At the moment it does little more than start up and display the Pivotal Chicken*, but it does contain Cedar specs that run on and off the device.