geek + red sox + cooking = peter ryan

Over the weekend I spent some time working on some generators for SeaCucumber the javascript testing framework I am working on with Mike Ward. There is quite a bit of redundant HTML code that serves as plumbing to the framework and a generator would simplify that.

I found the most useful generator documentation is on the RoR wiki: Understanding Generators.

The generator code itself was very simple although it will be interesting to try for a more complex generator.

class SeacucumberGenerator < Rails::Generator::NamedBase
  def manifest
    record do |m|
      m.directory File.join('test/javascripts')
      m.directory File.join('public/javascripts')      

      m.file 'unittest.js', File.join("public", "javascripts", "unittest.js")
      m.file 'test.css', File.join("test", "javascripts", "test.css")

      m.template('javascript_template.js',
          File.join("public", "javascripts", "#{file_name}.js"))
      m.template('seacucumber_template.html',
          File.join("test", "javascripts", "#{file_name}_test.html"))
    end
  end
end

This generator does three basic things.

• m.directory - Creates directories if necessary.
• m.file - Copies static files without modification to the target directory.
• m.template - Executes the two templates using ERB and writes them to the target location.

I used a NamedBase which take an argument. For example I might run this:

script/generate seacucumber MyFunction

Rails::Generator::NamedBase exposes a number of accessible attributes which are created from the argument. The most useful thing this class does is provide a bunch of attributes you can use from the manifest or template. It takes a trip to the source code to find out what they all are. To save time I thought I’d list them along with their values which follow standard rails inflection rules:

• name MyFunction
• class_name MyFunction
• singular_name my_function
• plural_name my_functions
• table_name my_functions
• class_path (blank)
• file_path my_function
• class_nesting (blank)
• class_nesting_depth 0

Next I need to add a bit more sophistication to the templates I am generating to make them sensible for when someone is starting to develop a JavaScript function and needs to generate the Sea Cucumber plumbing.

I avoid writing fixtures for testing. They are cumbersome to write and management (particularly after the fact) is a hassle. When testing a model’s validations I want to work with a generally static model that only changes one or two attributes which illustrate the test condition I am working on. To this end I followed Luke Redpath’s blog post on BDD and models in particular that uses a more behavior driven approach to testing a model and it’s attributes.

As such in my rails projects now I like to use this Hash extension when defining the validation rules for my model.

module HashExtension
  def except(*keys)
    self.reject { |k,v|
      keys.include? k.to_sym
    }
  end
end

And then I can define a model’s allowed behavior using RSpec. For example:

describe "a test model" do
  def valid_model_attr
     { :name => "name", :age => 21}.extend(HashExtension)
  end 

   it "should be valid" do
      Model.new(valid_model_attr).should be_valid
   end

   it "should be invalid without name" do
       model  = Model.new(valid_model_attr.except(:name))
       mode.should_not be_valid
       model.errors.on(:name).should_not be_nil
   end

  it "should be invalid if age is under 21" do
       model  = Model.new(valid_model_attr.except(:age))
       model.age = 20
       mode.should_not be_valid
       model.errors.on(:age).should_not be_nil
  end
end

I can add as many tests as I want without defining several test specific fixtures which need to be updated when the validation rules for a model change. Using an attribute hash and except I can update one hash.

This technique gets a little more complicated when testing a model with a has_many / belongs_to relationship but I recently had success with that on this site I developed (www.clowndown.net). In that case I defined a test hash a such:

  before(:each) do
    @team  = Team.new
  end

  def valid_team
    {
      :name => "team name",
      :contact_number => "call me here!",
      :people => [valid_person, valid_person],
      :knowledge_of_chicago => "pretty good",
      :why_will_win => "might get lucky",
      :relationship => "great"
    }.extend(HashExtension)
  end

  def valid_person
    person = Person.new
    person.attributes = {
      :email => "email@email.com",
      :name => "My Great Name",
      :shirt_size => "L",
      :hometown => "Chicago",
      :team => @team,
      :occupation => "occupation"
    }
    person
  end

And I was able to write specs like this that used an object relation that focused on testing of the behavior of the has_many / belongs_to relation.

  it "is invalid with 1 person" do
    @team.attributes = valid_team.except(:people)
    @team.people = [valid_person]
    @team.should_not be_valid
    @team.errors.on(:people).should_not be_nil
  end

I was working recently on a simple RoR website and needed an easy way to display columns of data on the front page. The easiest possible query was a simple find(:all) but after that I wanted to divide the items returned into groups that would be rendered separately. I wasn’t aware of any grouping available in enumerable so I did a bit of a search and ran across this discussion thread. I didn’t read the entire thread (and it’s mention of Set::classify which I was not aware of) but liked the group_by extension it proposed.

module EnumerableExtension
   def group_by(store=Hash.new)
     self.each do |elem|
       group = yield elem
       (store[group] ||= []) << elem
     end
     store
   end
end
Enumerable.send(:include, EnumerableExtension)

@collections = Collection.find(:all).group_by do |collection|
        collection.name.to_sym
end
@left = collections[:left]
@right = collection[:right]

<%= render :partial => “left_well”, :locals => {:items => @left} %>
<%= render :partial => “right_well”, :locals => {:items => @right} %>