So, I have an iPhone, I have a Mac and I have some ideas. It seemed only right that I combine them and build an iPhone application. Only problem... I hadn't done C or C++ in years and Objective-C looked a bit daunting. But, what the hell, I took the plunge.
I am happy to report that it's not too bad. Working in xcode however is nowhere near as rewarding as IntelliJ or Eclipse. Just setting up my project to use ocunit (see update for more on this) so that I could start with some tests and step through my tests with the debugger required a few hours of searching the interwebs and some messing about (thanks Chris Hanson for this good short guide) . You'd think they would make creating a new project would add unit testing to it by default. It still comes as a surprise to me that people don't automatically write unit tests. Can software really be built effectively any other way??
All in all, the experience has been good. I'm just getting to the point now that I'm starting to put the GUI together. More to come on this.
Update: now that I'm building the GUI, I've switched to the Cocoa Touch sdk and it seems that ocunit does not work with it yet, which makes TDD (with ocunit) difficult. For now, I'm testing my classes with ocunit compiled against cocoa, then moving them to my cocoa touch application, but that's not a very good, or sustainable approach. The other options at this point are: write a simple testing framework; wait for apple to make ocunit compatible with Cocoa touch.
2 comments:
Kent Beck recommends writing a unit test framework as a good way to learn a language, so maybe you could kill two birds!!!
Testing Cocoa is not that obvious. I've tried several approaches over the years and I've now written up what I currently do, which I think is a very reasonable and easy approach:
http://erik.doernenburg.com/2008/07/testing-cocoa-controllers-with-ocmock/
Post a Comment