ActiveResource and Testing

Eric Mill

ActiveResource is a pretty amazing implementation of REST, made in Ruby, for Rails. By the Rails core. Invented by DHH. It’s got good credentials. Sadly, it did not make it into Rails 1.2, so there is tons of buzz about it, but very little in the way of actual resources and active discussion. The only thorough treatment of ActiveResource out there I can find is by a Rails core member, and it’s good. I’m not going to re-cover everything it says, so definitely check it out.

Taking ARes Out For a Test Drive

The idea is that you can do something like this:

class User < ActiveResource::Base = ""

u = User.find 1 = ""

By declaring a model in your app as inheriting from ActiveResource::Base (as opposed to ActiveRecord::Base), you get to work with remote objects as if they were local. User.find is doing a GET request to /users/1.xml (at in this example), and is doing a PUT request to /users/1. The PUT is actually a POST with a parameter _method=put, but its heart is in the right place. Of course, the site you’re getting objects remotely from has to support this, and the easiest way to do this is with the new map.resources helpers that did make it into Rails 1.2.

Now I have the opportunity to use ActiveResource at work, and I get to do it in the most educational way I can think of—replacing a developed local User model with a remote User model. Naturally, I have pre-existing tests written that I need to have pass in order for the refactor to be considered complete. The idea is that permissions for this app (and other, sister apps) will all be governed by a parent application, and each child app gets the permissions for the logged in user from the parent app. We decided the easiest way was by sharing the User model through ActiveResource.

I don’t need to change any user data, or search by anything but ID, so I really only need a show action implemented. And, because I’m not just replacing a User model, but also a Role model (User has_many :roles), I’m going to have to return additional data in the User object that acts like the Role model I used to have. I also have to omit certain fields in the remote User model that aren’t appropriate for the child app to know. Since it’s only one action, and it’s going to have to contort the data, I don’t want to do map.resources and override the remote User model’s to_xml function—it makes more sense to just make my own .rxml view and fake the resource. ActiveResource‘s to_xml format is very easy to fake, even including a has_many relationship.

At /tools/:tool_id/users/:id.xml:

xml.user do
  xml.tag! "first-name", @user.first_name
  xml.tag! "remote-id", @user.remote_id, :type => "integer"

  xml.roles do
    @user.roles_in(@tool).each do |role|
      xml << role.to_xml(:skip_instruct => true, :only => [:title, :context])

How to best test your ActiveResource models is an open question right now, as far as I can tell. There’s no documentation, or even blog posts, that I can find, but there is an http_mock file included with ActiveResource, that is used in ActiveResource in its own tests, to test itself. The setup in ActiveResource’s test file for Base looks (something) like this:

def setup
  @matz  = { :id => 1, :name => 'Matz' }.to_xml(:root => 'person')
  @david = { :id => 2, :name => 'David' }.to_xml(:root => 'person')

  ActiveResource::HttpMock.respond_to do |mock|
    mock.get    "/people/1.xml",  {}, @matz
    mock.get    "/people/2.xml",  {}, @david
    mock.put    "/people/1.xml",  {}, nil, 204
    mock.delete "/people/1.xml",  {}, nil, 200
    mock.get    "/people/99.xml", {}, nil, 404
    mock.get    "/people.xml",    {}, "<people>#{@matz}#{@david}</people>"

This approach is interesting, because instead of mocking out the behavior of the Person model, they’re creating a mock Internet for the Person model to talk to. And, instead of using YAML fixtures, they’re using XML fixtures. And, because ActiveResource’s XML format is so simple, they’re just making a hash with a root and calling to_xml, and that’s fine. That’s a lot to take in.

So here’s my method for integrating ActiveResources into my unit and functional tests, which for me only involved editing test_helper, and required no change to any functional or unit test files. I’m sure it’s not the best possible method, but it achieves my goal of not changing how I write unit and functional tests. Here’s an excerpt of my test_helper.rb:

def self.all_fixtures
  fixtures :other, :normal, :models

def self.user(name)
  path = File.join(RAILS_ROOT, "test", "remote_fixtures", "users", "#{name.to_s}.xml")
  return nil unless File.exists?(path) path

def self.remote_fixtures
  ActiveResource::HttpMock.respond_to do |mock|
    mock.get "/tools/1/users/2.xml", {}, user(:eric)
    # some ActiveResource requests append these empty parameters, in any order
    # and you can't seem to use regexps with HttpMock right now
    mock.get "/tools/1/users/2.xml?include=&conditions=", {}, user(:eric)
    mock.get "/tools/1/users/2.xml?conditions=&include=", {}, user(:eric)
    mock.get "/tools/1/users/3.xml", {}, user(:matt)
    mock.get "/tools/1/users/4.xml", {}, user(:paper)
    mock.get "/tools/1/users/0.xml", {}, nil, 404
    mock.get "/tools/1/users/.xml", {}, nil, 404

def users(name)
  case name
  when :eric
  when :matt
  when :paper

This is assuming I have XML files in test/remote_fixtures/users, named eric.xml, matt.xml, and paper.xml, that are the mock responses I want ActiveResource to think it is getting.

The primary drawback here is that I’m hard-coding specific fixture info into test_helper. I could address some of this by doing part of the logic dynamically, by reading filenames in the test/remote_fixtures/users directory. The secondary drawback is that you need to make sure remote_fixtures is being called in every test file. Since I was already using an all_fixtures helper at the top of each file to load in my YAML fixtures, I just included a call to remote_fixtures inside that, and I didn’t have to add anything.

ActiveResource is not at all meant to be ready for release, so any issues I have with it should not be taken as complaints, just as information to be aware of if you go to use it. The main issue that makes this process difficult is that every possible route ActiveResource could request needs to be listed in HttpMock; there’s no support for regular expressions. Depending on your app, there could be requests made to /users/.xml, or /users/0.xml, and if there is no mock route specified, an error will be thrown and it will halt your tests. Sometimes requests are made with empty parameters, like ?include=&condition=. I’m not clear yet on when this happens, but it does. Of course, using HttpMock may not be at all the way the developers of ActiveResource ultimately intend us to test ActiveResource objects; perhaps we will actually mock out the objects or the model, instead of The Internet.

Overall, my transition to using ActiveResource has gone very smoothly. The implementation is a beautiful example of the kind of convenience that REST is supposed to bring us. Even if it’s not part of Rails 1.2, I think it’s ready to be used, in at least small applications, right now.