Exploration Through Example

You can get it from the publisher, from Amazon, from Powell’s, from O’Reilly …

The publisher, by the way, says that probably the best marketing for the book is getting reviews up on Amazon.

Because FlexMock and RubyCocoa disagree about the use of method_missing, you need to use flexmock as follows:

flexmock(SomeSubclassOfNSObject)

If the method you want to mock isn’t already defined on SomeSubclassOfNSObject, you have to define it before mocking it:

class Watcher <  OSX::NSObject
  def observeValueForKeyPath_ofObject_change_context(
             keyPath, object, change, context)
  end
end

That is ugly and horrible, so I wrote some code to make the class for me. It’s called rubycocoa_flexmock. It’s used like the following. (I use Shoulda, plus I add some syntactic sugar of my own to FlexMock).

  CALLBACK=:observeValueForKeyPath_ofObject_change_context

  context “change callbacks“ do
    setup do
      @watcher = rubycocoa_flexmock(CALLBACK, 4)       # DEFINITION
      @observed = ObservableValueHolder2.alloc.initWithValue(’original‘)
    end

    should “include the keypath and changed object“ do
      add_observer(:watcher => @watcher, :forKeyPath => ‘value‘)   

      during {
        @observed.value = “hello“
      }.behold! {
        @watcher.should_receive(CALLBACK).once.    # USE
                 with(’value‘, @observed, any, any)
      }

    end
  end

rubycocoa_flexmock can take multiple name/argcount pairs. It’s annoying that you have to give it that information. The problem is that the dependence on an existing method happens within should_receive, but the number of arguments is only known in the following with message. And if you never give it a with, the number of arguments is never known. RubyCocoa is picky about Ruby argument declarations matching exactly what it knows from Objective-C, and I haven’t found a way around that.

The declaration of rubycocoa_flexmock is here. Not the greatest code I’ve ever written, but ’twill serve, ’twill serve.

This may be of use someday to someone trying to figure out their Cocoa bindings problem.

Summary: Do not bind some columns in a table to one array controller, others to another.

I’m using RubyCocoa 0.13.1. I had an NSTable bound to an NSArrayController (bound in turn to preferences). I wanted to replace that NSArrayController with an NSArrayController subclass. I proceeded in small steps. Here’s step 1:

* I made an empty subclass of NSArrayController, PreferencesController.
* I created an object of that subclass in Interface Builder by dragging in an NSArrayController (<== very important; don’t try using an NSObject) and changing its class.
* I changed the binding of one of my table columns from the NSArrayController to my new PreferencesController. Specifically, the keypath was “arrangedObjects.display_name”. I left the other columns bound to the original NSArrayController.

To my surprise, each cell in the rebound column was not the display_name string. Instead, each cell contained an array with all the display names. That is, rather than the column looking like this:

Dawn
Paul
Sophie

It looked like this:

(Dawn, Paul, Sophie)
(Dawn, Paul, Sophie)
(Dawn, Paul, Sophie)

The other columns displayed correctly.

(Note: this was the leftmost column. When I made the change to the rightmost column, all of them were messed up.)

The solution was to switch all the bindings to PreferencesController. Then all the columns behaved correctly.

I haven’t tried doing this with two pure NSArrayControllers, rather than one pure and one subclass.

I forgot to mention that I did a podcast with Daniel Steinberg:

Brian Marick on Ruby Cocoa and Testing
Who’s smart enough to program?

Brian Marick talks to Daniel Steinberg on a wide variety of topics. Brian asks, who’s smart enough to program?, and describes how he met Andy and Dave at the Agile Manifesto summit. He talks about using Lisp, Smalltalk and Ruby, and about introducing programming to testers. Brian also shares the secrets of Domain Specific Languages (DSLs), and of course, his new book on Ruby Cocoa: marrying Ruby with the uber-cool Mac OS X Cocoa GUI framework, and test driven development with Ruby Cocoa code.

The Pragmatic Bookshelf has other podcasts, too.

I was using FlexMock to test code using Cocoa NSNotifications. I discovered an odd thing, which might be useful to someone doing a Google search some day.

My setup code originally looked like this:

  def setup
    @observed = NSObject.alloc.init
    @watcher = flexmock(NSObject.alloc.init)
  end

The notification connection was set up like this:

    center = NSNotificationCenter.defaultCenter
    center.addObserver_selector_name_object(@watcher,
                 :posted, "name", @observed)

That didn’t work. FlexMock recorded no calls to posted. I discovered that it worked if FlexMock were given a descendent of NSObject instead of an NSObject itself:

  def setup
    @observed = NSObject.alloc.init
    @watcher = flexmock(SomeRandomWatcher.alloc.init)
  end

SomeRandomWatcher is a pretty simple class…

# Use this class when creating a mock that’s to receive a notification.
# I don’t know why you can’t use NSObject, but you can’t — the notification
# will not be received.
class SomeRandomWatcher < OSX::NSObject
end

You can find the rest of the code here: mock-example-notifications.rb. I have an idiosyncratic style for writing mocking tests. Explanation of the syntax I use is here.

You can run the example if, at some point in the past, you’ve installed these gems:

$ sudo gem install Shoulda
$ sudo gem install flexmock

Book site

I struggled using mocks in RubyCocoa. Here’s what I learned, using FlexMock.

I’m writing some tests to understand and explain the RubyCocoa interface to key-value observing. Key-value observing is yet another way for one object to observe another. (I’ll call these two objects the @watcher and the @observed.)

If I were describing a key-value observing test over the phone, I’d describe it as having four steps:

1. Set up the relationship between the two objects.

2. Change an attribute of @observed.

3. During that change, expect some @watcher method to be called. One of the arguments will be an NSDictionary that contains the values before and after the change.

4. Also expect that the value really truly has been changed.

Here’s how I’d describe it in code:

  def test_setting_in_ruby_style
    newval = 5
    during {
      @observed.value = newval
    }.behold! {
      this_change(:old => @observed.value, :new => newval)
    }
    assert_equal(newval, @observed.value)
  end

I have an idiosyncratic way of using mocks in Ruby. Notice the order in my English description above. I say what the test is doing before I say what happens during and after that action. But mock expectations have to be set up before the action. In Java (etc.) that requires steps 2 and 3 to be reversed. In Ruby, I can use blocks to put the steps in the more normal order. (You can see the definitions of during and behold! in the complete code.)

Since each of the tests sets up almost the same expectations, I hived that work off into this_change:

  def this_change(expected)
    @watcher.should_receive(:observeValueForKeyPath_ofObject_change_context).
             once.
             with(’value‘,
                  @observed,
                  on { | actuals |
                       actuals[:old] == expected[:old] &&
                       actuals[:new] == expected[:new]
                  },
                  nil)
  end

That’s a fairly typical use of FlexMock. I specify three arguments exactly, and I use code to check the remaining one. (There are components in the actuals NSDictionary that I don’t care about.)

Now I have to start to do something special. Here’s setup:

  def setup
    super
    @observed = Observed.alloc.init
    @watcher = flexmock(Watcher.alloc.init)
    @observed.addObserver_forKeyPath_options_context(
                @watcher, ‘value‘,
                OSX::NSKeyValueObservingOptionNew | OSX::NSKeyValueObservingOptionOld,
                nil)
  end

Normally, an argument to flexmock just provides a name for the mock, useful in debugging. However, key-value observing only works when the @watcher object inherits from NSObject. So I pass in an already-initialized object for FlexMock to “edit” and add mockish behavior to. It’s of class Watcher, which inherits from NSObject. But why not just use an NSObject?

I could, except for a helpful feature of key-value observing. Before each call into the @watcher, key-value observing checks if it responds to the method observeValueForKeyPath_ofObject_change_context. If not, it raises an exception.

If I just passed in an NSObject and gave FlexMock an expectation that it should_receive an observeValueForKeyPath_ofObject_change_context message, FlexMock would just attach that expectation to a list of expectations. It would not create any method of that name; rather, method_missing traps such calls to the method and then checks off the appropriate expectation.

Therefore, I have to create a Watcher class for no reason other than to contain the method:

class Watcher <  OSX::NSObject
  def observeValueForKeyPath_ofObject_change_context(
             keyPath, object, change, context)
  end
end

The method doesn’t have to actually do anything; it’s never called. Instead, FlexMock redefines it to trampoline a call to it over to message_missing.

You can find the rest of the code here: mock-example.rb.

Hope this helps.

I’m ready for people to review the first draft of my RubyCocoa book. Here’s the goal of the book:

With any complex framework, there’s a moment when you realize you finally have a feel for it—when faced with a new problem, you’re able to guess whether the framework addresses it, roughly how it will address it, and where to look to find the details. The aim of this book is to give you that feel for Cocoa and RubyCocoa. […]

You can fetch the most recent draft from http://www.exampler.com/tmp/drafts/current.dmg. It’s 80-some pages and contains the first six chapters:

• Introduction

• How Do We Get This Thing Started?: A fast introduction to RubyCocoa.

• Part 1: Building a Useful App

  • Working with Interface Builder and XCode: Drawing a user interface, putting code behind it, and debugging that code. Text fields and text views.

  • One Good App Observes Another: Extending the app to use interprocess communication to listen to another app. The Cocoa Notification system. Reopening Objective-C classes.

  • A Better User Interface: Buttons (and the default button), combo boxes (and first responders), and a highly decoupled app architecture.

  • Taking Advantage of Ruby: A DSL to make it easier to define actions, delegates, and methods that post or receive notifications.

Here’s what I’d like to hear about:

• Any parts you have to struggle to understand.

• Parts that move too slowly or too quickly.

• Whether the book is taking the right approach, or started with the right approach and has veered off track.

• Problems with the code samples. Don’t struggle to fix them—let me know and let me fix them.

• Whether you’d buy the book if the rest is like what you see.

Don’t bother with typos, grammatical errors, or layout problems (like highlighted words that run together or long identifiers that stick past the margins - those will get fixed in due time).

You can send comments to me directly or via the book’s mailing list.

Thank you.

I’m ready for people to take a look at a chapter. It’s actually the second chapter of the book. The introduction, covering prerequisites, the general plan of the book, its goals, what “Cocoa” is, etc.—that will probably be written last.

But to orient yourselves:

• I assume you know Ruby, but nothing about Objective-C, Cocoa, or building apps on the Mac.

• Rather than build the exposition from the outside-in, teaching you first how to draw user interfaces, I’m working from Ruby up. I start with Ruby, start adding Cocoa ideas and tools onto it. The first chapter is very much like that—I’ll let you be the judge of whether it works.

• Especially in the beginning of the book, I want people to start changing code and seeing what happens. Might as well take advantage of Ruby’s fast edit-run loop.

The chapter and associated code are distributed as a disk image.

What am I looking for? Don’t bother with typos, misspellings, grammar, awkwardly-placed figures, and the like: those will all get changed later. I’m interested in two things:

1. Did the approach work for you? Did this chapter flow in a pleasing and sensible way? Is there information inexplicably missing?

2. Where did you get confused or stuck, in either the text or the “try this yourself” sections? Why? What would have helped?

Thanks.

Further announcements will probably go only to the mailing list.

I’ve deferred work on Ruby Scripting for Leopard in favor of a new venture: a book on RubyCocoa. I had two reasons for doing that:

1. I’m unhappy with how difficult scripting is, not because of the scripting frameworks themselves, but because the apps’ interfaces are badly documented and buggy. A book documenting something that’s hard will sell less well than one documenting something easy.

   Is the bugginess going to change? Possibly, but the history of AppleScript doesn’t make me optimistic. However, this alone would not kill the book, or even defer it. But:

2. There are two competing scripting frameworks: rb-appscript and the Apple Scripting Bridge. I’ve been writing the same scripts in both. I have no particular opinion on their different approaches, but rb-appscript is more mature. I find myself using it first, then translating a script into Scripting Bridge.

   That’s a problem. If the book treats rb-appscript, whatever comes next after Leopard could conceivably do the same thing to rb-appscript as Time Machine is doing to backup software. But I just can’t convince myself that Scripting Bridge is ready for mainstream Rubyists. I could document both frameworks, but I can also wait and see how things shake out.

Sorry for the disappointment.

I’ll be announcing a review draft of the “How Do We Get This Thing Started?” chapter later this week at the book’s mailing list.