OCMock with iPhone dev, I Git in trouble with Bzr

Mo’ coding mo’ problems. I’d love to have a stretch where the compiler and the command line actually agreed with the way I do things. Where do I start? First I needed to revert one or two files in my project. So now I’m arguing with Git on the command line as I unsuccessfully try to revert files individually. After a long bout with documentation across three different sites obsessed with Linux I’ve determined that Git works only when you do Kernel development. (That wasn’t exactly my conclusion but with every how to and tutorial using Kernel dev as an example… I’m just saying!) I read something in the docs about not being good with individual file versioning then reluctantly gave up on Git because I was gitting nowhere with my real work. I fell back on BZR.

I like BZR. I don’t wanna learn it over again. I installed and learned it over a year ago and remember there were some fickle issues but I couldn’t remember what they were. I went back to the BZR docs which are decent quality like the SVN red book. I skimmed to what I needed to refresh on. I had questions like, “This works kinda like svn doesn’t it?” Unlike Git, the docs for bzr didn’t let me down reminding me that I could revert a single file without adding a cache or an index to my mental user model. BZR refunded my $250 investment in a Git headache with store credit to be used on a reduced priced BZR belly ache. Hack, hack, hackity-hack. Bam!

Oh yeah! Now I remember what I couldn’t do in BZR! I couldn’t create a repository following its easy setup documentation. Running “bzr init” in an established project directory keeps telling me that my svn client is too old. More trips down memory lane, Oh yeah, I remember installing or thinking about installing bzr-svn support! Was that on this Mac or on my Linux box? (I couldn’t remember what state my BZR install was in.) Because I like to play with plugins and break things I remember being extra careful with BZR and only installing bzrtools, the recommended tool. I couldn’t rememebr how bzr plugins worked and I also realized my bzr install was dated. How do you upgrade? There’s that experimental uninstaller pyhton script that you have to click around 5-6 times to get the link to. Did I install from a dmg or from fink? Where does fink put its packages? Wasn’t it /usr/bin/sw? Google trips to the fink documentation almost got side tracked by reading up on MacPorts.

Bill Cosby spoke of Alzheimer’s. He had this joke of his brain sending his body into a room to pick up some “thing”… his body being excited upon entering the room to pick up the thing and not knowing what the thing was. I’m reading fink documentation completely ignorant of why I sent myself here. I was excited about fink and what it could do for me. I saw blurbs about apt-get. “Hey, its just like Mepis installs!” Poor Cliff! Will he ever find the secret to the kingdom of iPhone unit testing?

Unit Testing! I have to get back to writing test first! Un-rolling my stack after finally remembering it was /sw not /opt/sw or some other dumb path, I finally figure out that I didn’t install bzr with fink. I could just download the dmg. The plugins are easy to manage right under $HOME/.bazarr/plugins. I do only have bzrtools installed. Removing bzrtools temporarily does not get rid of the svn error. I have to run bzr init-repo over a non-existant directory and eventually copy my git exported code there. (Did I mentioned how side tracked I got figuring out how to git export? Yes I knew I could just “rm -frd .git” but I needed to learn the non-existant official way in case I got bit by something I didn’t know!)

My project is imported successfully into bzr, my stack is just about unrolled, I think. There’s still the matter of the files I was trying to revert. The OCMock stuff that just wouldn’t work in iPhone land. After all that fuss I took an entirely different approach.

I tried again with a bare bones iPhone project. Using XCode 3.1.3 I created a “UnitTests” target (new feature in the later version of XCode). I added my original modified unit test for verifying OCMock is correctly attached to the project. (See attached OCMockInstallVerificationTest.m) It build the “UnitTests” target and all of the tests complete successfully. I then [cleanly] checkout OCMock and build it’s main target with no issue. I build its test target and all the tests run successfully. I copy OCMockObjectTests.m and OCMockObjectTests.h into my fresh iPhone project and build and I start seeing the errors I blogged about earlier, returning booleans. (I’m starting to believe typeof is supported differently in the iPhone SDK.) After commenting these out temporarily I get errors that “setExpectationOrderMatters:” isn’t a recognized selector. I comment out the two sequence tests that use this important feature (the main reason I wanted to upgrade) and build again. I finally get stumped at a Bus error. If I fiddle around (do diffs and what not) I could probably get to the test that causes the problem but I’m giving up for now. The net result is that you can’t do everything you might want to with OCMock on an iPhone project. This is a real let down, not from the developer of OCMock but from Apple.

Below are my two versions of OCMock’s unit tests. The first is my initial attempt at using OCMock from last year. It’s named OCMockInstallVerificationTest.m and is a stripped down version of the unit test suite from the project as of last year. The second is a snapshot of what I just pulled from OCMock’s svn repo today.

Tell a friend:

Like this:

Related

About the author

A Java software developer, working professionally in programming for over 13 years, I am skilled in various technologies including ObjC, Java, SQL, XML/XSL, scripting languages and more. With a certain passion for developing I love to mix humor with programming.