Between The Rails

A colleague of mind, Andy Kappen, just turned me onto some new hottness in Rake 0.8.0. Now, Andy doesn't have a blog, so I can't give him any link luv, but I can say that he and his crew held the #4 spot for Rock Band, so you know he's got some street cred. Unfortunately, a hardware failure and subsequent long turnaround time for repairs caused them to drop to the #22 spot.

Anyway, here are the Rake changes we'll focus on:

/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb

  
  class Task
    def invoke
    end
  end
  

/lib/ruby/gems/1.8/gems/rake-0.8.0/lib/rake.rb

  
  class Task
    def invoke(*args)
    end
  end
  

See the difference? In case you missed it, we can now call rake tasks with an arguments list (*args) instead of using environment variables.

Let's take a concrete example. Say you wanted to write a rake task to parse a given set of revisions from your subversion log. With Rake 0.7.3, the code might have looked like this:

  
  namespace :subversion do
    desc"Parse subversion log"
    task :parse_log do
      puts "parsing: svn log -r #{ENV['end_rev']}:#{ENV['start_rev']}"
    end
  end
  

And you could call this task with:

  
  rake subversion:parse_log start_rev=200 end_rev=250
  

Now, there is nothing wrong with that. But, with the new hottness that 0.8.0 and *args provides, you can refactor your task to:

  
  namespace :subversion do
    desc"Parse subversion log"
    task :parse_log, :start_rev, :end_rev do |t, args|
      puts "parsing: svn log -r #{args.end_rev}:#{args.start_rev}"
    end
  end
  

And call it like this:

  
  rake subversion:parse_log[200,250]
  

An added benefit of this new hottness is that our task descriptions will list the expected variables:

  
  > rake -T
  .
  rake subversion:parse_log[start_rev,end_rev]  # Parse subversion log
  

Simply sizzlin!

In my last post, Quit testing the framework!, I talked about my philosophy of testing without second guessing the Rails framework. I'd like to continue the conversation, this time focusing on the controller side of things. If you haven't read the previous post, I suggest you do it now. Otherwise, you might be a tad lost.

Ok, our controller: users_controller.rb

  
  class UsersController < ApplicationController
    def index
    end
  
    def activate
      @user = User.find(params[:id])
      @user.activate! if @user
      render :action => :index
    end
  end
  

We are going to focus on testing the activate action. Specifically, I want to focus on finding and activating the user. I'll save the rest of the specs for the download.

Here is what our initial specs might look like: users_controller_spec.rb

  
  describe UsersController, "responding to POST /activate" do
    before(:each) do
      @user = User.create(:status => "Some Status")
    end
    
    def do_post
      post :activate, :id => @user.id
    end
  
    it "should find a user" do
      do_post
      assigns[:user].should_not be_nil
    end
  
    it "should activate a user" do
      do_post
      assigns[:user].should be_active
    end  
  end
  

Let's look at the first spec. We are creating a post to the activate action and verifying that a user was actually found.

Do we actually need to verify that a User was found? Not really. How about we trust ActiveRecord and concentrate on making sure we call the proper find method. While we are at it, let's get rid of that nasty assigns[:user] junk. Personally, I think assigns should be reserved for confirming that we actually set an instance variable.

A little stubbing, a little mocking , a smidge of refactoring...

  
  describe UsersController, "responding to POST /activate" do
    before(:each) do
      @user = mock_model(User, :id => "1")
      @user.stub!(:activate!)
      User.stub!(:find).and_return(@user)
    end
  
    def do_post
      post :activate, :id => @user.id
    end
  
    it "should find a user" do
      User.should_receive(:find).with(@user.id)
      do_post
    end
  end
  

Okay, that feels a little better to me. We are just making sure that User.find is being called properly. Notice that we've stubbed User.find. As long as Rails is doing it's job, we shouldn't have to worry about testing the result of a call to find. A nice side effect is that we are no longer creating and destroy an actual database model for each spec.

Now that we've focused on finding the user, let's turn our attention to actually activating the user. Our initial spec was a lil' ikky. We still had that ugly assigns call. And, besides, we've already tested the activate! method back when we tested our model. How about we just make sure that activate! is called? Sounds good to me.

A bit more refactoring:

  
    it "should activate a user" do
      @user.should_receive(:activate!)
      do_post
    end
  

Ahoy! New hotness! Just make sure that activate! was called. Leave the rest of the details to our model spec.

And our testing rundown:

I've included the user model, controller and controller spec for your here: user.rb, users_controller.rb, users_controller_spec.rb

If you'd like the user model spec, it was included in my previous post.

As always, I welcome any and all comments. Please see the sidebar for instructions on sending me a message.

Enjoy!

I think one of the things that I appreciate most about Ruby on Rails is the fact that it provides an accessible framework for testing. Test Driven Development is a snap with Rails. Unfortunately, I think the ease with which we can create test cases with Rails can lead to creating either too many or the wrong kind of tests. Many times I see tests that are actually testing the Rails framework.

I think the easiest way to provide more detail is to work through an example. I'll be using RSpec for the testing framework. If you're not familiar with RSpec, you should still be able to translate the concepts with Test::Unit and Mocha (or similar stubbing/mocking framework).

Let's start with a simple model: user.rb

  
  class User < ActiveRecord::Base
    def activate!
      self.update_attribute(:status, "Active")
    end

    def active?
      self.status == "Active"
    end

    def deactivate!
      self.update_attribute(:status, "Inactive")
    end
  end
  

First, let's write a spec to test the activate! method.

  
  describe User do
    before(:each) do
      @user = User.new
    end  
  
    it "should update the user's status attribute when activating" do
      @user.activate!
      @user.should be_active
    end
  end
  

And the log from running the test:

  
  SQL (0.000142)   BEGIN
  User Columns (0.002444)   SHOW FIELDS FROM `users`
  SQL (0.000159)   ROLLBACK
  SQL (0.000181)   BEGIN
  User Create (0.000406)   INSERT INTO `users` (`status`, `updated_at`, `created_at`) 
  ...
  

Now, the spec looks innocent enough. We are calling the activate! method and testing that the status attribute was properly set . Wait! Wait! Wait! Think about that for a second... testing that the status attribute was properly set... Doesn't that mean that we are actually testing the results of update_attribute? Well, yes it does.

The thing is, update_attribute is part of the Rails framework. Do we really need to be writing more tests for the Rails framework? My opinion is no. What we really need to verify is that update_attribute is being called with the proper values. Let Rails handle the rest.

Let's modify our previous spec a bit:

  
    it "should update the user's status attribute when activating" do
      @user.should_receive(:update_attribute).with(:status, "Active")
      @user.activate!
    end
  

Now, this change is closer to what I like to see. We are verifying that update_attribute is being called. We are also verifying that we are asking Rails to update the status attribute with the value "Active". That should be all we need to test. Let Rails deal with update_attribute, you've got business logic to test...

A quick sidenote... Can you see a second benefit from our change?. Here is the log of our new test:

  
  SQL (0.000087)   BEGIN
  User Columns (0.002240)   SHOW FIELDS FROM `users`
  SQL (0.000133)   ROLLBACK
  

Did you see it? There is no call to the database for updating the status attribute. By letting Rails handle the framework testing, we are also saving ourselves a little bit of time by not accessing the database.

Mmmmm. Tasty! But, I want more (I've got an insatiable sweet tooth)... Let's move on and test the active? method.

  
  describe User do
    before(:each) do
      @user = User.new
    end  
  
    it "should update the user's status attribute when activating" do
      @user.should_receive(:update_attribute).with(:status, "Active")
      @user.activate!
    end

    it "should be active if status is 'Active'"do
      @user.activate!
      @user.should be_active
    end
  end
  

Once again, this looks fairly straightforward, doesn't it? Look again. We are relying on the results of the activate! method. Do we really want to be wasting the time it takes for Rails to call update_attribute to properly set the status? I certainly don't!

We know what our method should be doing. If status is "Active", return true. We don't need to navigate the Rails plumbing to test that. Let's make another small change:

  
    it "should be active if status is 'Active'" do
      @user.stub!(:status).and_return("Active")
      @user.should be_active
    end
  

Ah, that's better. We are verifying that we wrote self.status == "Active" correctly. No need to worry about update_attribute or the rest of the Rails core. We are now limiting our tests to code we wrote ourselves. And again, we aren't hitting the database to set the user's status. It's a win/win.

Here is the rundown of where our code is tested:

I've included the user model and spec files here: user.rb, user_spec.rb

Enjoy!

I love, love, love Capistrano 2. For the person in perpetual need of structure and symmetry, as I am, Cap 2 namespaces are a blessing.

However, there is another feature of Cap 2 that is almost as cool as namespaces... The ability to easily load your custom recipes. Let's look at a quick example...

First, you need to setup your project for Cap 2:

  
  sandbox > capify .
  

Once you've done that, you'll notice a new file in your project root named Capfile. The basic Capfile code is pretty simple:

  
    load 'deploy' if respond_to?(:namespace) # cap2 differentiator
    Dir['vendor/plugins/*/recipes/*.rb'].each { |plugin| load(plugin) }
    load 'config/deploy'
  

Notice that Cap 2 will look for recipes in each of your plugin directories. That's way cool. Also, take note that config/deploy.rb is the only other recipe that gets automatically loaded.

Now, if we take a little jaunt in our Wayback Machine to the beginning of this blog post, you'll remember that I love, nay, need symmetry. I think of Capistrano recipes as remote rake tasks. I realize that they can be so much more than that, but hey, humor me.

We store custom rake tasks in lib/tasks. So why not store our recipes in lib/recipes? Why indeed! I think we will.

First let's create our Solr recipe: lib/recipes/solr.rb:

  
   namespace :solr do
    desc "Start the solr server"
    task :start do
      puts "starting solr"
    end
  
    desc "Stop the solr server"
    task :stop do
      puts "stopping solr"
    end
  end 
  

Next, our monit recipe: lib/recipes/monit.rb:

  
  namespace :monit do
    desc "Start monit"
    task :start do
      puts "starting monit"
    end
  end
  

The final piece of the puzzle involves adding a single line to our Capfile:

  
    load 'deploy' if respond_to?(:namespace) # cap2 differentiator
    Dir['vendor/plugins/*/recipes/*.rb'].each { |plugin| load(plugin) }
    load 'config/deploy'

    # Load recipes from lib
    Dir['lib/recipes/*.rb'].each { |recipe| load(recipe) }
  

All we did was mirror the directive for loading plugins with a slight twist. Rather than looking in plugins directory, we focused our attention on lib/recipes.

And now, for the moment of truth:

  
  sandbox > cap -T
  .
  cap monit:start          # Start monit
  cap solr:start           # Start the solr server
  cap solr:stop            # Stop the solr server
  sandbox > 
  

Ahh! Symmetry achieved.

I was recently watching Geoffrey Grosenbach's third PeepCode episode focused on rSpec: rSpec Controllers and Tools.

At one point during the screencast, while working with Heckle, Geoffrey mentioned that it is easiest to run heckle against a single instance method of your own making due to the fact that all objects that are subclassed from ActiveRecord::Base have all the AR methods globbed in. No need to heckle Rails itself, eh? By the way, if you are unfamiliar with Heckle, Kevin Clark has a great overview.

The thing is, I want to heckle all my methods at once. A little A - B and a rake task is all it took.

  
    namespace :spec do
      desc "Heckle a class"
      task :heckle => :environment do
        unless ENV.include?("model")
          raise "usage: rake test:heckle model=User"
        end

        #The user is allowed to test a single method
        #with User#activate! or similar
        inputs = ENV["model"].split("#")

        model = inputs[0].capitalize
        test_prefix = "#{model.downcase}"
        klass = Object.const_get("#{model}")

        #First check to see if user provided
        #an instance method name. ex: User#activate!
        methods = [inputs[1]] if inputs.size == 2

        #If the user only passed in a model name,
        #we need to get the instance methods that
        #are not part of ActiveRecord::Base
        methods ||= klass.instance_methods - ActiveRecord::Base.instance_methods

        methods.each do |method|
          cmd = "spec spec -H #{model}##{method}"
          system(cmd)
        end
      end  
    end
  

If you would like to heckle all the methods for an object (we'll user a User object as an example), run the following:

  
    > rake spec:heckle model=User
  

You can heckle a single method like so:

  
    > rake spec:heckle model=User#encrypt
  

You can download this task as well as it's Test::Unit counterpart here: heckle.rake

The rake tasks have beend DRYed up a little so that we can run most of the same code regardless of whether you are using rpsec or Test::Unit.

Enjoy!

Sometimes when I'm building a Rails application, I want to rebuild my database from scratch. No problem you say? Just provide a lil' lighting? A lil' thunder? Or perhaps:

  
     rake db:migrate VERSION=0
     rake db:migrate
  

Well, yeah. That works if you only need to rebuild the database structure. But I often find myself writing plenty of rake tasks to bootstrap different parts of the system. For example:

  
  namespace :bootstrap do
    desc "Bootstrap a set of admin users"
    task :admins => :environment do
      puts "Bootstrapping admins"
    end
  
    task :categories => :environment do
      puts "Bootstrapping categories"
    end
  
    task :zip_codes => :environment do
      puts "Bootstrapping zip_codes"
    end
  end
  

Now, how would I go about running all these tasks at once? I could create an :all task that called each of bootstrap tasks:

  
    namespace :bootstrap do
      desc "Call all the bootstrap tasks"
      task :all do
        tasks = %w[admins categories zip_codes]
        tasks.each do |task|
          Rake::Task["bootstrap:#{task}"].invoke
        end
      end
    end
  

This is fine if you only have a few tasks. But what if you add a new bootstrap task and fail to add it to the task list in :all?

My solution was to find a way to get all the tasks in a particular namespace. After reading through the Rake rdocs and fumbling around a bit, I finally resorted to bugging Mr. Rake himself, Jim Weirich, who provided the hint I needed:

Task manager objects are just objects that respond to the protocol required to hold and manage tasks. Currently, only the Rake::Application class responds to this protocol, but the task manager responsibilities were separated out into a module to make the list of required responsibilities more clear. You can get the current rake application object via: Rake.application

Ah! Rake.application. That's the ticket! So, here is what I ended up with:

  
    namespace :bootstrap do
      desc "Call all the bootstrap tasks"
      task :all do
        tasks = tasks_in_namespace("bootstrap")
        tasks.each do |task|
          Rake::Task["#{task.name}"].invoke
        end
      end  
    end

   private
     def tasks_in_namespace(ns)
       #grab all tasks in the supplied namespace
       tasks = Rake.application.tasks.select { |t| t.name =~ /^#{ns}:/ }
       
       #make sure we don't include the :all task
       tasks.reject! { |t| t.name =~ /:all/ }
    end
  

You can get the sample file here: bootstrap.rake

A little rake luv is all you need:

  
  > rake bootstrap:all
  Bootstrapping admins
  Bootstrapping categories
  Bootstrapping zip_codes
  

Enjoy!