RSpec 4 iPhone BDD?

Is anybody doing this yet? I made an effort to use RSpec for iPhone development almost a year ago but got stumped on Ruby mock objects that didn’t seem to to play nice with CocoaTouch objects. I got a lot closer than my blog post would lead you to believe but stopped due to deadlines, and my lack of experience with both Ruby and ObjC. Tonight I dug up the old project and tried to remember where I left off…

…Aahh it’s al coming back to me now! I had wrapped the MockObject support in Ruby to ensure it received parameters from CocoaTouch. For some silly reason parameters passed directly from CocoaTouch objects are dropped/ignored by whatever mock framework Ruby is using with RSpec. Forgive me for not knowing more about the internals but I don’t do Ruby and this was from last November. Here’s an example of the RSpec I modified to allow parameters to pass cleanly. It also has the buddings of a dynamic message dispatch thingy I couldn’t get working because it makes no sense to hard code every anticipated method invocation. If one of you Ruby guys could jump in and patch this up or if somebody could point me to an already viable alternative that’d be so swell…

require File.dirname(__FILE__) + '/test_helper'

require "BowlingController.bundle"
OSX::ns_import :BowlingController
OSX::ns_import :BowlingProtocol
require 'delegate'

include OSX

class ObjCMock
  attr_accessor :delegate
  def roll(num)
  # def method_missing(m, *args)  
  #   puts "Forwarding message"
  #   @delegate.send(m, args)
  # end
  def initialize(theMock)
    @delegate = theMock

describe BowlingController do
  before(:each) do
    @controller =
    @bowling = mock('BowlingProtocol')
    @controller.bowling =
    @text_field = mock('Pins')
    @controller.pins = @text_field

  it "should roll a ball" do

  it "should roll a ball and get the value from the pins outlet" do

  it "should be an OSX::NSObject" do
    @controller.is_a?(OSX::NSObject).should == true

  it "should have an outlet to a bowling object" do
    @controller.bowling = @bowling

  it "should send the pin value to the bowling object" do
    #This line wraps the mock with the class defined above
    @controller.bowling =
    #The following line will cause failure calling directly into the mock
#    @controller.bowling = @bowling

  it "should have an outlet to the score" do
    @score = mock('Score')
    @controller.score = @score

//  BowlingController.h
//  BowlingController
//  Created by FIXME on 2008-11-10.
//  Copyright 2008 FIXME. All rights reserved.

#import "BowlingController.h"
#import "BowlingProtocol.h"

@implementation BowlingController
@synthesize pins;
@synthesize bowling;
@synthesize score;

-(void) roll{
	int val = (int) [self.pins intValue];
	printf("Value is: %i", val);
	[self.bowling roll:val];


// This initialization function gets called when we import the Ruby module.
// It doesn't need to do anything because the RubyCocoa bridge will do
// all the initialization work.
// The rbiphonetest test framework automatically generates bundles for 
// each objective-c class containing the following line. These
// can be used by your tests.
void Init_BowlingController() { }

We will miss MJ

God rest his soul, Michael Jackson moved on yesterday. I don’t normally post about pop artists but this is Michael Jackson, plus I got Gospel classics playing on Pandora (Carlton Pearson – He Lives) and it kinda sets the tone for more serious writing. It goes without saying the Michael was a pop icon and possibly the most recognized and talked about person on the planet. We all have our favorite songs and most of them are likely from one of his first couple of solo albums. You know where you were when you first tried to do the moonwalk. You know how you felt when your buddies lied and told you how you were gliding. “Are my feet right? Was that the move?” Don’t act like it was just me! How many of you kicked somebody else in the face trying his signature leg lift? And I’m not the only one that almost got a nose bleed trying to find the last “authentic” copy of his “Beat It” jacket (with all the zippers) from the swap-shop. Forget the tabloid nonsense that everyone brings up. We know he had problems but who of us doesn’t have any secrets? What if somebody came up in the back of your closet with the 300 watt flashlight shining all on yo’ underwear stains? Let the man have his legacy, stop bringing up the dark stuff. Michael was a legend that changed the way we all danced… sang… watched TV… talked (Sha’mon! What the heck does sha’mon mean?)… dressed… and wore our hair. (Say what you will but you know you had a curl or some sort of wet look back then!)

That’s what’s happening

Lots of stuff missing my radar. First off, AOL/MapQuest is getting with it. If you don’t know where it’s at now you know. you’d think I’d have something to do with it but I don’t. We’re doing all kinds of live stuff lately. Most important is the dropping of MapQuest 4 Mobile on the iPhone. This project, code named Ice internally, was my first attempt at iPhone hackery. It became the #1 navigation app on its release date yesterday. A small team of us at MapQuest hooked up with a larger team in AOL and the end result is something I’m proud to have played a part in. If that’s not John Blazed enough for you then there’s the bit on Maxwell. One of my favorite artists is making his comeback and y’all gotta show him some love. All this and more comin at’cha from AOL. I wish I could ramble more but there’s some particularly difficult stuff I gotta get back to.

Steve will come back at the release date of the new software version for iphone 3G

This has been confirmed by an unidentifiable but highly reliable source who commented here. (How do we know the source is reliable? We’ve confirmed that by not revealing his identity.) While we all “looked forward” to the return of Steve Jobs we now have the guarantee of his return to Apple. Look for stock prices to jump by close of business tomorrow when an undisclosed press release scheduled for select members of the media is said (By whom? The unidentifiable source! That’s whom!) to announce the return of the black shirt wearing mogul to the Apple empire. Also revealed by our insider, Apple decided to delay the release of iPhone 3G Os until absolute time period that coincides with the time slot of Steve’s official return to Apple. Remember where you heard it first! This breaking story along with others has been brought to you in part by:

Juxtaposition: With just as many letters juxtaposed you get a tax deposition or something close in spelling. No doubt Juxtaposition is responsible for the confirmation of many rumors floating around the internets.

HBCU: While not directly responsible/knowledgeable of any content posted here, makes it easy to connect with friends, create, share and discuss your status, share your photos, and help the development of future Historical Black Colleges and University (HBCU) students all while putting an emphasis on getting the word out about campus happenings. Its this very ease of connectivity that results in the majority of our internet communications.

J2MEPolish: For getting those tough hard to reach stains out of the crevices or your mobile phone try J2ME polish. It removes more stuck-on dirt than the leading polish.

TechKnow: GI Joe said, “Knowing is half the battle”. The other half is knowing which half you’ve won. If you don’t know, now you know… y’know? If not, drop by TechKnow and tell’em I sent you.

Don’t listen to me! XCode and SVN 1.5

A little while ago I posted a great idea involving hacking your prestine XCode install so’s you could take advantage of SVN 1.5 without shelling out dollars for extra tools. As it turns out I had my manager shell out dollars for extra tools. If you visit my site enough you’ll notice a pattern in where I profess to know something that I just read from someone else’s blog minutes ago, thus bolstering my ego, adding cool-points to my imaginative reputation, and thrusting myself on a pedestal slightly less than double the elevation yours. You’ll also notice that most of what I say here should be taken with a grain of salt (and two, that’s exactly two, packets of Splenda). Lengthy story decapitated, my tip for SVN/XCode, while truly functional, would create problems in any existing web-share you have configured for your Mac. (Web Sharing is the little apache daemon that is controlled by the check-box in the “Sharing” preference pane which is invoked by calling up Spotlight, typing share and mashing the enter key.) If you followed my instructions step by step then you can recover by spinning the record back. That means follow my directions in reverse order. Merely dump all of your svn-bkup files back into /usr/lib/ and be done with it.

Recently Apple released iPhone SDK 3.0 beta and with it XCode version 3.1.x. (The SDK may just as well be XCode though I believe it’s available/usable outside of XCode if your hard core enough and your middle name happens to be Gnu. Also I can’t remember the digit for ‘x’ so shoot me!) In the release notes… you know those little things that tag along with new software? Yes I read the release notes because they tell you what’s bundled in the release. Anyhow, in the release notes they announce that XCode now supports SVN 1.5! Yay 1.5!!! I was just about to try to upgrade to Svn 1.6 by the by. So I roll back my earlier 1.5 hack because I wanna finally be able to use web sharing and viola! I no longer can use SVN from XCode! Maybe I should try running the installer again. Maybe I should just stop hacking my internals…

TDD and the warm-fuzzy Un-learning curve…

I’ve been interacting with many more developers in my current company than I ever had in other companies over my career. One pattern I’m noticing is the warm/fuzzy philosophy. That is when somebody gets really comfortable with a certain way of doing things then you show them a new thing. Eventually they will find a way to use or associate the new thing with the way they always do things in order to get that warm/fuzzy feeling of, “it’s just like the other thing.” Hi, I’m Cliff. You’re here because you were probably looking for a product like Sham-Wow, Googled “warm fuzzy“, and clicked on a link to my crazy site. While you won’t find anything that sops up 32oz of Kool-Aid from your hard-woods after a three-year-old decided to play monster trucks on the kitchen table, you will get a lesson on how to forget what you thought you knew. Wait a minute, I forgot where I was going with this. You’ll get a lesson on why you should forget what you thought you knew. How to displace that knowledge is an exercise best left to the reader… (You, being that reader… you don’t get much exercise do you? Not with all the online reading and stuff.)

So when I talk to people and explain TDD (hereafter referred to as “the solution”) I usually get the response “it’s kinda like that system I used back at my other job only then we didn’t automate. We were just…”? Better? Honest? More careful? Clever? “Yeah back then we used to catch all of our bugs and…”? Re-fix them? Explain them as features? Double them? I occasionally get responses like, “you really don’t need to test first to get good code.” Let me ask a question. Have you ever seen good code? Chrysler 300 What does it look like? Does it where a tight-knit skirt and flirt from the corner? Does it come with a “HEMI” label, high RPMs, dual exhaust and chrome wheels? Is it tucked between two all beef patties, special sauce, lettuce, cheese, pickels, onions and a sesame seed… What does it look like, really?

What should it look like?
Call me crazy but I believe code (good, bad, ugly, and indifferent) should look like your spec. Do you know what your spec looks like? No you don’t! Because it just changed! Look again. There, it changed again! A decent spec is like a chameleon. It constantly changes colors, shapes, sizes. (For the record, chameleons don’t change shapes/sizes unless you put them in a blender. It has been proven that such a device, when activated, can render a chameleon very small and suddenly change both the size and appearance of the creature.) A poor spec is like a TV guide from 1976. It’s nostalgic to think about what was showing back then but of no use to anybody that wishes to figure out which station to tune to catch Judge Judy at 7:30EST. That is, a poor spec doesn’t tell you what you code should look like right now or what it should look like tomorrow. Did you catch that? I just explained that you need a TV guide to figure out what your code should look like tomorrow… not just any TV guide either. You need tomorrow’s TV guide, well, because it has tomorrow’s TV listings. Let that sink in a moment while I grab some coffee.

“Writing tests is like the ECMO system we had back at Rutherford And Son’s company. ECMO was the Enhancement/Change Management Officer in charge of each project. That person was a developer in charge of reviewing your code prior to commits and…” What was ECMO looking for? “We shouldn’t waste time futzing with tests… We just need to designate a [insert warm-fuzzy here]” What does any warm/fuzzy recreation of last year’s change management solution attempt to find? Defects, violation of practices, and unapproved system calls/libraries come to mind as common things to look for. What does any of this have to do with the spec? What does that spec look like again? “Who cares! We’re about to land some code, man! Plus we have approval for the EZ-Test framework which comes with new improved static analysis support.” (Ever wonder how new-improved some products really are?)

What Bad Code looks like
The unfortunate side effect of warm-fuzzy is that it fools you into believing that you’re creating good code. We all have seen Jeff Atwood’s Horror code examplesBad Code so there’s no question of what bad code looks like, right? Bad code has a smell. We don’t write no stinky code here because we have ECMO! (Trumpets blare to the sound of the Nightly News theme song introducing Brian Williams.) Warm-fuzzy overlooks an important but subtle point of the agile philosophy. Agile is not practiced to get good code, it’s a means of getting correct code. We’ll come back to that point in a moment. Let’s forget warm fuzzy for now. Let’s forget all we remember about ECMO. Let’s forget everything we were ever taught about good code, bad code, Dallas Cowboys and the Indiana Pacers.

The UnLearning Curve
Because technology constantly evolves our understanding of it must evolve. People learn things by association which makes picking up new technology and concepts a challenge. With technology you can flip a bit in a micro-processor and dramatically alter the flow of an application. Subtle changes can reveal brand new concepts that are completely disassociated with our understanding. (Try explaining the subtle change of a pointer variable vs. a regular variable which holds an address rather than a value to a Comp. Sci-101 student who only knows Java or VB.) In short, we have to unlearn to evolve. Remember the goto statement? An entire evolution of sub-routine evangelists had to scrub the planet and assassinate all other developers on the planet before “goto” finally got removed from modern languages. Believe it or not, there’s another similar revolution happening between those who do/don’t program with assignment statements. (Maybe one day they’ll remove the equals symbol from your favorite language… sounds far-fetched but so did dropping goto.) Those who lived by the word “goto” were hung up on it’s warm/fuzzy benefits so much that when you explained a subroutine to them they understood only to the point where it would return back to the caller. You truly had to changed your views/ideas/opinions on program flow and structured thinking in order to “get” subroutines. Simply stated, to learn new technology you often have to dis-remember old technology… the benefits in particular.

The Solution doesn’t care about good code
That’s a strong statement to make, but if you ask anyone who understands the true benefit of any philosophy from “the solution” they’ll tell you that it’s perfectly acceptable to use it with bad code. In fact, some may encourage you to write bad code in order to get a green bar. Better stated, instead of getting the code right you want to get the right code. If I pay you $50K for transportation what will you build me? A car right? Not just any car but a nice sports car with variable five speed transmission, anti-lock brakes, dual suspension and an auto-defog mirror. Nice! Good for you! I’ll go drive you’re treasured car into the ocean because I needed transportation to return to Jamaica and visit my long lost relatives. (What did your transportation spec look like again?) I would have been soo much better off with a shoddy rowboat than I’d ever be with my soggy car. Sure you got the transportation tool right. You even went as far as to pre-load my favorite MP3s. That’s how lots of people work because they’re stuck in “go” mode. Management says go! Get it done!

With software it’s soo much more dangerous because we can be creative and sorta dig ourselves out of the ocean. Many developers, after loading Method Man’s “Tical” to the in-dash mp3 storage, would eventually realize that the delivery date is approaching and maybe they should ask for a destination. I love it when we get to this point because that’s where the creativity truly begins. You might see fins under the tire, or a possible grappling hook that fires to attach to the complimentary aircraft – yet in design. Rarely and only in the most extreme cases does the car get dismantled.

To the left
The solution puts the focus on the left [consumer-facing] side of the code (which is why we lefty’s have so much fun with it!) The shape of the calling code becomes more important than the shape of what others refer to as “the real code”. It feels awkward because we think of ECMO. It feels redundant and slow because we already visited the left side of the equation. We know what we’re doing and we don’t want to waste time obsessing on the left side of the product. How many times should we keep asking “you want me to build you some transportation, right?” So to appease other people who obviously think it’s important, we ask a few more questions, like “where are you headed?” When we get a typical answer like, “far away to see my family” it further underscores the time wasted on the left. We then assume total control of the decision making process because our customer is clueless. “You’re obviously going to need dual overhead cam for speed since it’s so far away”, we think to ourselves. Many of us have gotten so good at it that we could literally assemble half the car before asking a third question.

I would continue my babbling but I have to cut it short because I’m off topic. The general idea is lost up there somewhere I’m sure. For all my people that understand where I’m going here speak out and nobody will care. Nobody will care because you’re expressing your opinion here rather than on Slashdot or Stack Overflow, or some other popular network. Here it’s just you, me, and the chickens… and the chickens have automated regression suites so we should listen to them instead. I now step down from my soap box and yield to the poultry.