The Snepo Blahg

Ruby is such a great language, and we use it for all sorts of development; from simple scripting to full blown web applications. One of the things I like about it, is the way it is integrated into all sorts of platforms and frameworks and OS-X’s Cocoa framework is no exception. As of X-Code 3 the RubyCocoa scripting bridge is a part of the whole framework. For a Ruby programmer, it makes hacking up an OS-X app simple and quick.

Of course personally I’d never use this for a big heavy full blown Cocoa application, that’s what Objective-C is for, but for taking something simple. Well that’s a different matter.

First we need to understand a little bit about how the framework actually works. If you’re a Ruby guy and you’ve used Rails, you’ll start to feel comfortable, since Cocoa is an MVC (Model View Controller) framework, so the abstraction is similar to that of Rails (or Merb or Camping or numerous other frameworks out there). Models are classes just like they are in Rails, as are Controllers. Views however are made up of NIB files, which are created by the Interface Builder Application.

What we’re going to do is to create a simple echo app, that can take an input, and echo it back to you reversed. Trivial, I know but it does help to explain some core concepts about how Cocoa and Ruby work together.

Let’s get started

Start a new project in X-Code 3 and select the Cocoa Ruby Application option to create an application framework with the Ruby Scripting bridge.

In the classes folder on the left add a new file and name it MainController.rb. Paste the following code into the MainController , so that it looks like this:

require 'osx/cocoa'
class MainController < OSX::NSObject
    ib_action :display_message
    ib_outlet :text_field, :text_display

    def display_message(sender)
      @text_display.setStringValue(@text_field.stringValue.reverse)
    end
end

You’ll first notice the two methods, ib_action and ib_outlet, these two methods allow us to map methods and instance variables to our NIB file (remember our NIB is our View), these methods come courtesy of OSX::NSObject which we inherit from.

Next double click the NIB file MainMenu.nib, this will launch the Interface Builder application and we can begin to build our View.

From the Library on the right, find NSTextField and drag two of them onto the Window, then also find a Push Button, and drag it onto the Window and rename it to Echo.

Your window should look something like this:

Now it’s time to wire things up. Firstly we need to instantiate an object from MainController. From your library find Object (it’s the blue cube), and double click it, it should pop up in your MainMenu.nib window.

Now highlight it, and select the Tools -> Identity Inspector from the menu. Under class select MainController, you’ll see it populate with the methods and instance variables we set in MainController with ib_action and ib_outlet earlier.

Now for the tricky bit of Interface Builder. Press the control button and drag from the Main Controller instance in the MainMenu.nib file on to the top Text Field on the Window, you should see a popup listing your two instance variable. Select text_field(this make the instance variable @text_field an instance of NSTextField), do the same again for the other NSTextField and select text_display.

Then Control click from the Echo button back up to the MainController instance, and this time you should see our ib_action display_message, this maps the action of this button to the method, display_message.

Guess what, that’s it, you’re done. Save the work you’ve done in Interface Builder and quit it, head back to X-Code and select the Build and Go option. Viola when you enter some text in the top box and then click then echo button, you’ll see text reversed below it.

Mocking and what the hell?

Ok, you might be asking yourself what the hell is this guy talking about. Let me start by saying this. If you could build your application from the outside in, wouldn’t that assist you in delivering a better product?

What I mean of course, is that as developers we tend to think in ways of how to store data? How can I make it fit my idea of a relational database? So we start with UML documents, schema’s, migrations and all that guff. We start from the inside and work our way out. We get this fantastic architecture that we love, we’ve toiled over it after all, it’s like a child, and god dammit I’m not giving it up for nobody.

Welcome client

With bold new ideas, and assumptions that you as the poor developer had no idea about.

bq.Wait, that won’t fit into my architecture!

Now I know what you’re thinking, “this is just one of the things with being agile, you need to let go”. I agree whole heartily, but it doesn’t make it any easier to try and fit a square peg into a round hole.

Now imagine if you could develop the majority of your controller code (assuming you’re using an MVC architecture) and get a really good practical idea – assumptions aside – that you could develop from. It’s lean and really simple to change.

rSpec to the rescue.

Mocking and stubbing is a part of rSpec these days, and since I’m a Ruby guy, I’m also an rSpec guy, so all the examples here are in rSpec, however the principles remain the same regardless of language.

Mock objects are imitation objects that give you declarative control over their behaviour in the course of the execution of an example

Personally I always found this a little confusing, so in my own words, Mocks are a way for you to use object that don’t exist, or to pretend that you have an object that you in fact don’t have. Let’s look at an example.

 it "should mock an Event class since we haven't written that yet" do
  @events = mock(["Event 1", "Event 2"])
  User.should_receive(:find).with(:all).and_return(@events)

  events = User.find(:all)

  events.should eql(@events)
 end

Before you run this… It won’t work, I’m presuming we have no models/schema at all, so there is no class called User as yet.

 it "should mock an Event class since we haven't written that yet" do
  User = stub!(:user) unless Class.constants.include?("User")
  @events = mock(["Event 1", "Event 2"])
  User.should_receive(:find).with(:all).and_return(@events)

  events = User.find(:all)

  events.should eql(@events)
 end

We’re now “stubbing” in an object to use in place of the User class. The difference between a “mock” and a “stub” is that a mock has an expectation of being used, i.e. that if a mock object is not used, it will cause the test to fail. It’s an expectation in itself. A stub however is just a simulated object, there is no expectation placed upon it. Note also I’ve got unless Class.constants.include?(“User”), that way if and when you do develop a User model it will be used instead of the stubbed object.

This all seems quite pointless…

If you’re feeling like the above examples are pointless, well, you’d be right. Realistically that is a useless test. So lets look at a real example.

 describe LoginController do
   it "should authenticate a user" do
     User = stub!(:user) unless Class.constants.include?("User")
     user = mock("A logged in user")
     User.should_receive(:authenticate).with('login' => 'cbarrie', 'password' => 'oohhhh').and_return(user)

     post :authenticate, :user => {:login => 'cbarrie', :password => "oohhhh"}
     response.should redirect_to(admin_url)
   end
 end

Controller tests/specs are the one place that mocks and stubs are awesome. When testing controllers, it’s a bit of shame to be testing code, that you’ve already tested elsewhere, 1. it’s slower, 2. fixtures in the database are fragile, and 3. ActiveRecord is already heavily tested. Why test the whole stack each and every time you run your controller tests/specs? It just makes it hard to find the errors.

In the above example we now have the opportunity to test – in isolation – a method in the controller without the need to test the User class. Our authenticate method on the User class should already be tested in a separate test, there is no need to hit it twice. More so we don’t even need to have a User class at this point in time to run this.

Now you can test in isolation and begin developing with an environment that can easily adapt to the changes required by business owners.