Archive for November, 2009

ActiveResource::HttpMock doesn’t mock hard enough

Thursday, November 19th, 2009

I’ve got a family of (ARes) resources that are available through an external web service.  These resources are used pervasively throughout my site -they appear on about 75% of my site’s pages.  When testing, of course I don’t want to hit the web service and endure the vagaries of performance and availability.  The nice people developing ActiveResource seem to have accommodated this desire by providing the HttpMock class.

But…  HttpMock is very exacting in its demands for matching requests -it’s all or nothing.  That means that if I make fifty different requests, all identical save for a tiny change in the URL params, I need to make fifty different mocks.  Ouch.

So I decided to mock the mocker.  No, really.  Using mocha, I mock the HttpMock::Request#== method to always return true.  Now, regardless of the request path, HttpMock always sees a match and returns my mock data.

The denouement, using the Rails docs as a starting point:

def setup
  @matz  = { :id => 1, :name => "Matz" }.to_xml(:root => "person")
  ActiveResource::HttpMock.respond_to do |mock|
    mock.post   "/people.xml",   {}, @matz, 201, "Location" => "/people/1.xml"
    mock.get    "/people/1.xml", {}, @matz
    mock.put    "/people/1.xml", {}, nil, 204
    mock.delete "/people/1.xml", {}, nil, 200
    req_res = mock.get "/", {}, "Constant Data Goes Here", 200
    req_res.last.first.stubs(:==).returns(true)
 end
end

git bisect… taste great when served with Edge Rails.

Monday, November 2nd, 2009

So I’ve got a couple of projects that I like to claim run on “Edge Rails”.  But the reality is that I let them slip for a month or two before playing catch up.  Today I decided to update an application that had somehow gotten behind 2-3-stable by hundreds of commits.  Being bold, I jumped straight to HEAD and was met with a shower of sparks running rake.  Where to start?

In a word or two: git bisect

I started the bisection run and told git that head was bad and my current commit was good.  Note: I use a git submodule to track Rails…

[…vendor/rails]# git bisect start

[…vendor/rails]# git bisect good

[…vendor/rails]# git bisect bad 2-3-stable

(and in another terminal window)

[myapp] # rake

Then it was just a matter of marking each auto-selected commit as good or bad with git bisect good or git bisect bad.  Worked great.  Next time, I’m going to automate the whole thing with git bisect run.