I’ve been writing a fair number of functional tests recently, one thing that kept cropping up was the need to check if a form had been rendered and that it was going to perform a particular action. Shoulda has a should_render_a_form macro, unfortunately it’s been depreciated and doesn’t do anything other than check a form element has been rendered in the view.

I decided to come up with my own macro that checks the specifics of a form element, enter should_render_a_form_to. This takes tree arguments, a description, an options hash and a block that contains the expected url. You would use the macro as follows…

should_render_a_form_to("create a new post", {:method => "post"}) { new_user_post_path(@user.id) }

should_render_a_form_to("update a post", {:method => "put", :id => "post_edit_form"}) { user_post_path( :user_id => @user.id, :id => 1) }

The macro code is available on github with test coverage. If you just want to cut and paste into your own macro’s file:

def should_render_a_form_to(description, options = {}, &block)
  should "render a form to #{description}" do
    expected_url  = instance_eval(&block)
    form_method   = case options[:method]
      when "post", "put", "delete" : "post" 
      else "get" 
      end
    assert_select "form[action=?][method=?]",
                  expected_url,
                  form_method,
                  true,
                  "The template doesn't contain a <form> element with the action #{expected_url}" do |elms|

      if options[:id]
        elms.each do |elm|
          assert_select elm,
                        "##{options[:id]}",
                        true,
                        "The template doesn't contain a <form> element with the id #{options[:id]}" 
        end
      end

      unless %w{get post}.include? options[:method]
        assert_select "input[name=_method][value=?]",
                      options[:method],
                      true,
                      "The template doesn't contain a <form> for #{expected_url} using the method #{options[:method]}" 
      end
    end
  end
end

The macro checks for both the forms action attribute as well as the hidden input rails uses to specify the method where necessary. I’ve also been playing with creating a macro to check for a form with specific fields such as should_render_a_form_with_fields. This is proving to be slightly more difficult than I originally anticipated and defining a nice interface to the method has been rather tricky.

I’ve just had to setup Hoptoad for one of our apps that uses Vlad for deployment, the integration isn’t quite as easy as with Capistrano. I couldn’t find much information on how to integrate the two so I thought I’d share my solution.

The original Hoptaod task for use with Capistrano needed a little modification.

task :notify_hoptoad do
  rails_env = fetch(:rails_env, "production")
  local_user = ENV['USER'] || ENV['USERNAME']
  notify_command = "rake hoptoad:deploy TO=#{rails_env} REVISION=#{current_revision} REPO=#{repository} USER=#{local_user}" 
  puts "Notifying Hoptoad of Deploy (#{notify_command})" 
  `#{notify_command}`
  puts "Hoptoad Notification Complete." 
end

fetch is a Capistrano method so needed to be removed, we can use the Vlad environment pattern for this. I also wanted to use the git information for the user instead of the system user, finally as far as I can tell the git commit SHA being deployed is not available in Vlad.

In the Vlad deployment script I added a Hoptoad task to replace the default Capistrano task provided by Hoptoad.

task :notify_hoptoad => [:git_user, :git_revision] do
  notify_command = "rake hoptoad:deploy TO=#{rails_env} REVISION=#{current_sha} REPO=#{repository} USER='#{current_user}'" 
  puts "Notifying Hoptoad of Deploy (#{notify_command})" 
  `#{notify_command}`
  puts "Hoptoad Notification Complete." 
end

Then added it as a dependency for the deploy task

task :deploy => [:update, :migrate, :start_app, :notify_hoptoad]

There are a couple of helper tasks I’ve added to get the git user and the SHA of the commit being deployed

remote_task :git_revision do
  set :current_sha, run("cd #{File.join(scm_path, 'repo')}; git rev-parse origin/master").strip
end

task :git_user do
  set :current_user, `git config --get user.name`.strip
end

What a weekend, it all started on Friday night, a feverish last minute planning session began on how we would implement wuzlr.com. We’d bounced around some ideas earlier in the week and had a pretty good idea of what we wanted, whittling that down into a set of features we could implement in 48 hours was no easy task, there was so many good ideas we didn’t have time to implement them all. The at 1am it all began…

The Pitch

If your office is anything like ours things get pretty serious whenever a game of table football breaks out (especially when @theozaurus is playing). We’ve wanted a way to track who’s the best in the office for quite some time, finally we have just the thing, and so do you. Wuzlr is a table football league tracking application that lets you see performance over time with all sorts of fun and interesting facts and figures displayed.

Wuzlr (or wuzler if you use the correct non web 2.0 spelling) is the Austrian word for table football and just so happened to be the first domain we came across that’s still available. We also liked the hat tip to the ‘e’ dropping crowd, no not you party people, I’m talking about flickr and the like.

Application Features

• Create leagues and record all your games, Check out the Jiva office league
• Compare yourself to other players, Me Vs. Theo
  
• View your nemesis, best team mate, worst team mate and more, my player page
• League standings, games played per day, table bias, most dedicated players (who’s put the most time in)
  

Our Team

• Jamie Dyer @kernowsoul Developer for Jiva
• Theo Coushion @theozaurus Developer for Jiva
• Peter Coles @fatelvis Designer for Existem

Yes we know the site looks terrible in IE, who uses IE anyway?

I’m a big fan of autotest for testing, unfortunately it does stress my poor MacBook Pro and makes the fan go berserk if running anything other than the most simple of test suites. This is due to autotest having to check each file in your project for changes.

No more will autotest stress out my mac, autotest-fsevent is a great gem that uses OS X’s FSEvent system to be notified when files have changed rather than having to poll each file. You need mac OS X 10.5 or later to take advantage of FSEvent.

The other nice thing autotest-fsevent does is take care of all the .autotest config options, I managed to delete my entire config file which I’ve been tweaking for as long as I can remember trying to get the perfect setup.

I can now run even the most demanding of test suites and my computer barely breaks a sweat. Thanks bitcetera, my computer ♥’s you.

Today I’ve been writing tests for a legacy Rails application I inherited recently. The application has several user roles, each role having varying permissions. To deal with this nicely I setup shoulda macro’s to create contexts for each of the user roles, public user, standard user, admin user etc. then in my tests I could write…

public_context do

  context "on GET to :index" do
    setup do
      get :index
    end

    should_redirect_to("root url") { root_url }
  end
end

signed_in_user_context do

  context "on GET to :index" do
    setup do
      get :index
    end

    should_redirect_to("user url") { user_url }
  end
end

This is pretty standard practice now and something I picked up from looking at the code produced by the guys at Thought Bot. While working on the test suite it became apparent many of the methods behaved in the same way for multiple user roles. I wanted to come up with a way to run a group of tests under multiple user roles without having to duplicate any code. Shoulda macros to the rescue again! After creating another macro to deal with multiple contexts I can write my tests like this…

multiple_contexts 'public_context', 'signed_in_user_context' do

  context "on GET to :show" do
    setup do
      @advert = Factory(:advert)
      get :show, :id => @advert.to_param
    end

    should_render_with_layout :application
    should_render_template :show
    should_not_set_the_flash
    should_assign_to( :advert ) { @advert }  
    should_respond_with :success
  end
end

And the shoulda macro code itself…

def multiple_contexts(*contexts, &blk)
  contexts.each { |context|
    send(context, &blk) if respond_to?(context)
  }
end

def public_context(&blk)
  context "The public" do
    setup { sign_out }
    merge_block(&blk)
  end
end

def signed_in_user_context(&blk)
  context "A signed in user" do
    setup do
      @user = Factory(:user)
      sign_in_as @user
    end
    merge_block(&blk)
  end
end

I’ve updated the javascript_auto_include plugin to include changes from abradburne and jimp79. Thanks to these guys the plugin now supports nested controllers so you can add javascript to a paths like admin/users and admin/users/show/1 etc.

After floating around without a proper home the javascript_auto_include plugin now has a nice cosy permanent home on my website. I’ve also added an update for Rails 2.x compatibility submitted by davidsch.

You can find the official plugin page under the Rails Plugins heading on the right. Or visit the javascript_auto_include page link.