The ever evolving test suite

I've been working on a rather http://www2.blogger.com/img/gl.link.giflarge rails project and have watched my testing style evolve. And this next step, inspired by Jay Fields has really got me excited. Take a peek.

class Test::Unit::TestCase
  class << self
    def test(*names, &block)
      test_name = :"test_#{names.join('_').gsub(/[^\w ]+/, '').gsub(/ +/, '_')}"
      raise ArgumentError, "#{test_name} is already defined" if self.instance_methods.include?( test_name.to_s )
      if block_given?
        define_method( test_name, &block )
      else
        define_method( test_name) do
          $stderr.puts "Incomplete test '#{names.join(', ')}' @ #{caller.last}"
        end
      end
    end
  end
end

What the above method does is allows for very "fast and loose" test definitions. For example, I can do the following:

class Foo < Test::Unit::TestCase
  # This is a place holder test, and when ran will 
  # print a warning
  test 'this will print a warning when the test runs'

  # This is a genuine test
  test 'this will assert true' do
    assert true
  end
  
  # This is another genuine test, but I'm providing visually 
  # putting the test in another namespace
  test :index => 'should render a list' do
    assert_template 'list'
  end
end

Ultimately, I'm extremely satisfied with how this works. My functional tests can have test definitions with a prefix of the action.

I have updated my Textmate so I can Run Focused Unit Tests, as well as having test highlighted like other keywords (alias, class, require, etc.)

Hpricot, screen_scrape, and horrible pages

I'm an avid Dungeons and Dragons player and have decided I'm going to make a Rails application that will help consolidate the rules for personal use.

So I decided to do a screen scrape http://www.wizards.com/default.asp?x=dnd/lists/feats . I wanted the list of feats. To get to the table, and each row of feats, here was the xPath I used:

"/html/body/table[2]/tr[2]/td[3]/table/tr[3]/td/table[4]/tr/td/table/tr"

Of particular note, I was having trouble with the tbody in xPath, so I removed those references. Let me tell you, without Firebug's copy xPath, I would've went insane getting this out.

So I ask, why the heck does Wizards of the Coast use table based layouts. They hurt my brain hurt.

If you are interested here is the code that I wrote. It doesn't have any underlying tests, but I ran the import without fail, so for now, its good enough for me.

class Feat < ActiveRecord::Base
  validates_presence_of :name, :description
  belongs_to :rule_source

  class << self
    # Run the import, first getting the RuleSources
    def import!
      File.open(File.dirname(__FILE__) + '/feats.html', 'w') do |f|
        f.puts (open("http://www.wizards.com/default.asp?x=dnd/lists/feats").read)
      end
      doc = File.open(File.dirname(__FILE__) + '/feats.html') {|f| Hpricot(f) }

      RuleSource.parse_rule_source(doc)
      
      parse_feats(doc)
    end
    private
    def parse_feats(doc)
      feats = (doc/"/html/body/table[2]/tr[2]/td[3]/table/tr[3]/td/table[4]/tr/td/table/tr")      
      feats.pop     # Get rid of the results count

      feats.each_with_index do |feat, index|
        parse_feat(feat) if index > 1
      end
    end
    def parse_feat(feat)
      ... Do the actual parsing of the row ...
    end
  end
end

class RuleSource < ActiveRecord::Base
  validates_presence_of   :code, :name

  class << self
    def parse_rule_source(doc, publisher = nil)
      (doc/"div.keyboxscroll/table/tr").each do |source|
        if source_code = (source/"td[1]")
          source_code  =  source_code.inner_html.strip
        end
        if source_name = (source/"td[2]/i")
          source_name  = source_name.inner_html.strip
        end
        
        find_or_create_by_code_and_name( source_code, source_name )
      end
    end
  end
end

Single Table Infuriation

Single Table Inheritance in Rails is an excellent pattern that works really well, except when it doesn't.

class Parent < ActiveRecord::Base
end

class Child < Parent
end

class GrandChild < Child
end

Each of the above classes are defined in their own files (app/models). There are times in development mode that I've noticed that Child.find(:all) will generate the following SQL:

SELECT * FROM parents WHERE (type='Child')

In Rails 1.2 the fix for this is perhaps a little obfuscated.

class Parent < ActiveRecord::Base
  require_dependency 'child'
end

class Child < Parent
  require_dependency 'grand_child'
end

class GrandChild < Child
end

Now, the other part of this solution is that you probably want to call require_dependency at the end of the class definition as there may be methods in the parent object that the child object needs. I suppose you could re-open the class at the end of the file.

capture, binding and other diabolical machinations

For the South Bend Ruby Group I volunteered to talk about form builders for February. At the time of volunteering, I knew close to nothing about form builders. I decided to take the upcoming meeting as a reason for learning about the builders. And now I'm hooked.

But that is not the point of this particular post. What I'm talking about is the bizarre magic involved in the form builder. In a project that I've been working on we have a need for rendering lists both in tables and in lists. However we'd really like to re-use the view logic in generating the list. Its pretty much a matter of hot-swapping the tags appropriately.

<% list_for(@list) do | l | %>
  <% l.caption 'Hello World' %>
  <% l.header_row(:id => 'list_head') do %>
    <%= l.header_cell 'title' %>
    <%= l.header_cell 'edit' %>
    <%= l.header_cell 'delete' %>
  <% end %>
  <% l.row( :class => 'spam', :id => 'hot_dog') do | list_item | %>
    <%= l.cell l.title %>
    <%= l.cell 'edit_link' %>
    <%= l.cell 'delete_link'  %>
  <% end %>
<% end %>

We opted to create a builder class. You call :list_for, and can optionally pass a builder class (like the one below). Of particular note there is use of bindings and captures. I'm still a bit dazzled by what all is going on (and wrote the tests to make sure it all works). Below is my understanding of what is going on.

1) There is the :concat method (as defined in the ActionView::Helpers::TextHelper module). We are taking the results of first parameter and appending it to the proc's binding. The proc's binding is the result of the stuff in that proc. In the case of the above :list_for its all of the text generated :list_for's block.

2) There is the :capture method (as defined in ActionView::Helpers::CaptureHelper module). This little critter packages up the input block as text. I tried using block.call but this didn't work as intended (I got double the block text). If I didn't want the option of passing options to each of the elements, I could conceptually simplify the method by doing a manual opening of a tag, block.call, then manually closing the tag. This could be a performance piece that I will implement at a later point (though I'll need a Hash#to_markup_attributes method).

def list_for(object, *args, &block)
  raise ArgumentError, "Missing block" unless block_given?
  options = args.last.is_a?(Hash) ? args.pop.symbolize_keys! : {}
  builder = options.delete(:builder) || ListTableBuilder
  builder.new(object, self, options, &block)
end

# <table>
#  <caption>
#  <tr>
#    <th />
#  </tr>
#  <tr>
#    <td />
#  </tr>
# </table>
class ListTableBuilder

  # Welcome to the insanely bizarre initialize function
  def initialize(collection, template, options, &proc)
    @collection, @template, @proc = collection, template, proc        
    @options = options.reverse_merge( :class => 'list', :id => 'list')
    @template.concat( @template.content_tag('table', @template.capture(self, &proc) , @options ), @proc.binding)
  end

  # :options are applied to content_tag('td')
  def cell(text, options = {})
    @template.content_tag('td', text, options)
  end

  # :options are applied to content_tag('th')
  def header_cell(title, options = {}) 
    @template.content_tag('th', title, options)
  end

  # :options are applied to content_tag('caption')
  def caption(text, options={})
    @template.concat( @template.content_tag('caption', text, options), @proc.binding )
  end

  # :options are applied to content_tag('tr')
  def header_row(options={}, &block)
    raise ArgumentError, "Missing block" unless block_given?
    @template.concat( @template.content_tag('tr', @template.capture(&block), options) , block.binding)
  end

  # Options
  # The options will be added to each row.  
  # :class will append and not destroy the internal classes
  # :id will be used as a prefix for the internal id generation
  def row(options={}, &block)
    raise ArgumentError, "Missing block" unless block_given?
    options.symbolize_keys!
    @collection.each do | c |
      row_options = options.reverse_merge( :class => '' )
      row_options[:class] += ' ' + @template.cycle('odd_row', 'even_row')
      row_options[:id] += '_' + @template.send(:dom_id, c)
      @template.concat( @template.content_tag('tr', @template.capture(c,  &block ), row_options), block.binding )
    end
  end
end

Ruby Cookbook from O'Reilly

Ruby Cookbook: Recipes for Object-Oriented Scripting
by Lucas Carlson & Leonard Richardson

ISBN 0-596-52369-6

I haven't read this book cover-to-cover, but I have given it a very thorough inspection, skimming through sections to find points of interest and then stopping to read those recipes. So, actually, I've probably read a whole bunch of the book and didn't realize it.

The book is written in a very concise manner, with plenty of examples, lots of useful code, excellent cross-references and a very generous license that allows you to use the code from the book (albeit with some restrictions).

Each recipe is presented as a quartet of Problem, Solution, Discussion and See Also sections. Each problem is presented succinctly, and the solutions dive right into the required code (with code comments explaining some of the more complicated lines of code, but not explaining the self-documenting lines). The discussion section of each solution really digs into what is going on, code choices that were made, variations, and basically anything else that might be interesting. The see also section cross-references other recipes that may be pertinent to the given problem.

All told, this book does an amazing job of going through a wide range of problems, from Strings & Numbers to Meta-Programming & Rails and Graphics. This book is loaded with useful bits of information and I would highly recommend adding it to your collection.