Dynamic and Concise

A Study in Array#Collect

2007-12-04T17:14:00Z

Stephen Chu talked about how to beautify statements like customers.collect { |customer| customer.name } in one of his posts. Dr. Nic also has a post talking about the same thing. It's very interesting to see so many people want to get away the cumbersome collect syntax and I am one of these people.

To beautify the collect syntax when we need just one field such as customer.name. There are several ways:to use Stephen's syntax:
customers.collect_name

Dr. Nic's:
customers.names

And guess what, if you are using Rails, it comes with a Symbol extension method called to_proc. What the method does is to turn a symbol into a simple Proc object. so we can say:

customers.collect &:name which does the job.

In practice, I always just use this built-in to_proc because it's free as long as you are on a Rails project. And there is no reason for me to justify I should spend time to make it even more magical.

Stephen also came up with syntax like:
customers.collect_name_and_id

The method always returns an array of arrays ([['Yi', 1], ['Du', 2]]). The syntax looks very nice, but I think it has limited value because I may not want an array of arrays, I may want an array of hashes ([{1 => 'Yi'}, {2 => 'Du']), or an array of strings, then the method has no use or we have to do more magic. Most importantly, when we want multiple fields from a model object to form some kind of data structure, we probably should ask ourselves first: what's the business meaning for this action? If we can find one, we can just add one method, returning whatever we want, to the model class we are dealing with and use that method for collect.

For example, if I want to send an email to several people and their email address should look like:
people.collect{|person| "person.name <person.email>"}, then I probably will just add a method to the Person class, such as Person#full_email_address and return the string I need. the the syntax for collect can be simplified to people.collect &:full_email_address.

It's cool to see how powerful method_missing can be with Stephen's extension, and how lovely Ruby is.

Why I hate test coverage tools

2007-11-19T21:42:00Z

Because it could lie if we abuse it. I have been in one project where people count acceptance tests (written in FIT) so the test coverage always looks pretty high when the unit tests coverage are actually poor. But the figure gave people there false confidence that their code is in good shape.

In another project, a test had only two lines of code, but it actually ran about 5 seconds and touched a lot of code underneath. So by this test alone, it improved the test coverage a lot, looks pretty good eh? Then wait until it failed sometimes. People had absolutely no clue on why it failed and where it caused the failure. and then we could spent one hour to just pinpoint where the problem is. For me, this test is simply just not a test and should be replaced by a bunch of more fine-grained unit tests.

The test coverage number is just a number. It helps when the number is low so that you know you have serious problems in your project. But when the number is high, it doesn't mean anything. We could still do something with it, such as browsing through the nice colored reports to see where we failed to test and if we should fix that. But we should never trust we are in good shape just because the number is high.

To make our test coverage more meaningful, we should remember that TDD is a tool to help us designing our code, to improve the code quality. If we feel awkward in writing a test, then we know there is something wrong in our code and we should refactor that piece, instead of just writing a bad test or just be off.

When RSpec meets Validatable

2007-11-12T16:36:00Z

Jay Fields writes an excellent module called Validatable to provide a class who include the module the ActiveRecord like behavior. For example, you can say validates_presence_of :attribute etc. This page has the RDoc of the module. When I write RSpec for a Validatable class, I ended up writing a stattement like this:

   
   @email.validate_only("presence_of/body") 
   @email.errors.on(:body).should_not be_nil

Which is basically testing body is a required field. It works, but it looks complicated and hard to understand. The RSpec on Rails plugin provides a method error_on so that I can say something like this:

 model.should have(2).errors_on(:attribute)

This is much more readable than the previous one. I came up with a small extension on Validatable so that I can have a better syntax for testing Validatable. Here's the spec:

require File.dirname(__FILE__) + '/../../../spec_helper'

module RspecValidatableSpec
  class Thing
    include Validatable
    attr_accessor :age
    attr_accessor :name
    validates_presence_of :age
    validates_numericality_of :age
  end
end

describe RSpecValidatable, 'a validatable object' do
  before :each do
    @thing = RspecValidatableSpec::Thing.new
  end
  
  it "should tell you it has at least one error on a field" do
    @thing.should have_at_least(1).error_on(:age)
  end

  it "should tell you it has one error on a required field" do
    @thing.should have(1).error_on_presence_of(:age)
  end

  it "should tell you it has one error on a numerical field" do
    @thing.should have(1).error_on_numericality_of(:age)
  end
end

describe RSpecValidatable, 'a validatable object' do
  before :each do
    @thing = RspecValidatableSpec::Thing.new
  end

  it "should tell you it has no error on a field" do
    @thing.should have(:no).errors_on(:name)
  end
end

You may need a different path to your spec_helper.rb to make it work. I got the "traditional" errors_on just like how RSpec works on ActiveRecords. What's more, Validatable has a validates_only method which allows us validating only one type of error on one attribute. so I can have even better control than RSpec on Rails giving me over ActiveRecords. For example, I can specify what type of errors I expect to have. The only problem is that validates_only raises an error if you check an attribute on a validation that is not specified. So a nice spec like

email.should have(:no).errors_on_presence_of(:attachment)

is not quite possible. For those of you who are interested in this, here is the actual code:

module RSpecValidatable
  def errors_on(attribute)
    self.valid?
    [self.errors.on(attribute)].flatten.compact
  end

  def respond_to? method_name
    super(method_name) || method_name.to_s.index('error_on') == 0  
  end
  
  def method_missing(error_on_method, attribute)
    reason = error_on_method.to_s.sub(/error_on_/, '') 
    self.validate_only("#{reason.to_s}/#{attribute.to_s}")
    [self.errors.on(attribute)].flatten.compact
  end
  
  alias :error_on :errors_on
  
end

Validatable.send :include, RSpecValidatable

Law of Demeter and Forwardable

2007-11-02T18:26:00Z

Dan Manges has an excellent post explaining Law of Demeter and when it makes sense to use Forwardable to comply the principle, or I should say when it doesn't make sense to use the module.

The point is, use it when it makes sense. Take his example, customer_name is just not a sensible method for an order. Asking an order for its customer name is a wrong question because all the order should care is who is its customer. The name is irrelevant to the order.

In fact, I think by putting cusomer_name method in an order. the encapsulation is actually broken because now an order knows the inside details of a customer, thus tightly coupled these two classes.

Fluent interface for Ruby delegation

2007-10-29T22:26:00Z

This is a link to Bryan's blog for Fluent interface for Ruby delegation. We used it in our codebase for better (read: more readable) syntax. You might be interested in.