Adventures with Ruby

Suppose you have an index page with people and you want to have a series of neat filters to show a selection of people. For example only the people still alive of only the adults. How would one do that?

I like the method of using a named_scope and delegating to specified filters. This way, you can structure your filters properly and get clean URLs. Also, you can chain other named scopes to the filter.

This is an example of how I would do that.
Read more

A short one for today: How do I write YAML files?

Well, to get the prettiest results, I do something like this:

def write(filename, hash)
  File.open(filename, "w") do |f|
    f.write(yaml(hash))
  end
end

def yaml(hash)
  method = hash.respond_to?(:ya2yaml) ? :ya2yaml : :to_yaml
  string = hash.deep_stringify_keys.send(method)
  string.gsub("!ruby/symbol ", ":").sub("---","").split("\n").map(&:rstrip).join("\n").strip
end

Read more

The old subject of nested forms comes back again to hunt me. Rails 2.3 has the new and shiny accepts_nested_attributes_for feature. I like it, but there are some things to take into consideration. Adding a child object through javascript remains a bitch to tackle. So I sat down and wrote some javascript. Here is what I came up with. Not sure if I’m going to release this a plugin though.

First of, build the models. I have a project with many stages:

class Project < ActiveRecord::Base
  validates_presence_of :name
  has_many :stages
  accepts_nested_attributes_for :stages, :allow_destroy => true
end

class Stage < ActiveRecord::Base
  validates_presence_of :title
  belongs_to :project
end

Read more

I was browsing through the gem documentation today, and I found a command that I didn’t know existed.

sudo gem cleanup

It removes old versions of your installed gems. You can of course specify the gems you’d like to cleanup.

I have been playing with the matchers that Thoughtbot’s Shoulda provides, and they are very cute!

For instance, a controller can be easily tested like this:

describe ArticlesController do
 
  integrate_views
 
  describe "the index action" do
 
    before :each do
      stub(@article = Article.new).id { 1337 }
      mock(Article).all { [@article] }
      get :index
    end
 
    it { should route(:get, articles_path).to(:action => :index) }
    it { should respond_with(:success) }
    it { should render_template(:index) }
    it { should_not set_the_flash }
    it { should assign_to(:articles).with([@article]) }
 
  end
end

As you see I’m a fan of rr as well. I love the sleek and concise syntax it offers, just as the Shoulda matchers.

So, now what?

Well, I don’t like to spec views separately. It’s too much of a drag to set up all the required instance variables, because there tend to be a lot of them. That’s why I use the integrate_views command. I do want to spec some essential elements rendered in the view. Just knowing that no exceptions were thrown is not always good enough.

The solution is the have_tag matcher. This is actually a wrapper around assert_select, allowing you to use CSS selectors to check your view. I ended up testing links to certain actions, to ensure all the actions are reachable for the user. For example:

it { should have_tag("a[href=#{article_path(@article)}]") }

Yuck! That is a lot of noise! The whole use of RSpec is to create human readable tests. Also, there is a lot that can go wrong here. I will easily forget one or more of those differently shaped brackets. I want to write something like:

it { should have_link_to(article_path(@article)) }

Much cleaner! Making a matcher for this isn’t that difficult:

module CustomLinkMatcher
 
  include Spec::Rails::Matchers
 
  def have_link_to(url)
    AssertSelect.new(:assert_select, self, "a[href=#{url}]")
  end
 
end

Don’t forget to activate it, though:

Spec::Runner.configure do |config|
  config.include CustomLinkMatcher
end

So, why go through all this trouble? Why should I even care? I mean, the have_tag selector isn’t that unreadable, just a bit cluttered. Well, I found that the ease of which you can type specs is directly related to how extensive you test. If a test is difficult to type, hard to read, or feels repetitive, most people (with possible exception of Bryan Liles ) will get annoyed with it and don’t do it anymore.

To give myself as an example. I never cared much about heckle. Heckle could mutate so much code, I soon stopped caring. Now, with the matchers Shoulda gives me, I like running Heckle! I know keeping Heckle happy shouldn’t be a goal, and I accept certain things Heckle will heckle me about even now, but writing specs like this really made my tests much more robust!

So, in conclusion: if you find yourself hating to write certain specs, try to refactor your specs so it becomes easy and fun! Try to write tests as you would like your tests to be written. Testing should be fun! Keep it that way! Use every gem, tool and technique you have to do so!