Dan Manges

First Class vendor/gems

Dan Manges — Sat, 19 Apr 2008 03:30:44 GMT

A common way to add gems to vendor/gems is by using the gem unpack command.
cd vendor/gems
gem unpack the_gem_name

And then loading them up using an approach like this, this, or something like this:


Dir.glob(File.dirname(__FILE__) + "/../vendor/gems/*").each do |path|
  gem_name = File.basename(path.gsub(/-[\d\.]+$/, ''))
  $LOAD_PATH << path + "/lib/"
  require gem_name
end

This feels like it should be unnecessary since Rubygems comes with a method to load a gem (gem). It's really a second class way of using gems.

Here's a solution I've been using for a while to keep gem code in vendor/gems, but still load them using the regular gem method.

First, a rake task to install gems.


namespace :gem do
  desc "install a gem into vendor/gems"
  task :install do
    if ENV["name"].nil?
      STDERR.puts "Usage: rake gem:install name=the_gem_name"; exit 1
    end
    sh "gem install #{ENV['name']} --install-dir=vendor/gems --no-rdoc --no-ri"
  end
end

Then, a little Rubygems magic to change GEM_PATH (I placed it at the top of environment.rb).


require "rubygems"
Gem.clear_paths
gem_paths = [
  File.expand_path("#{File.dirname(__FILE__)}/../vendor/gems"),
  Gem.default_dir,
]
gem_paths << APPLE_GEM_HOME if defined?(APPLE_GEM_HOME)
Gem.send :set_paths, gem_paths.join(":")

Finally, using gems works in typical Rubygems fashion.


# somewhere in the code base
gem "hpricot", "0.6"
require "hpricot"

I like this gem install approach better than the gem unpack one. Gem dependencies are being added to Rails in 2.1, which should make this unnecessary. When I first looked at the code, it was using gem unpack, but also extracting the gem specification. I'm not sure if setting gem_path like this could simplify the Rails implementation or not.

I only tested this approach on a Rails 2.0.2 app, using Rubygems 0.9.5 and 1.1.1. One additional benefit is that if you want to make sure your app doesn't depend on any locally installed gems, you can make vendor/gems the only directory in the gem path (although CruiseControl should be helping you with that problem anyway).

The Practicality of the RSpec Story Runner

Dan Manges — Fri, 22 Feb 2008 06:25:16 GMT

On an internal ThoughtWorks mailing list, somebody recently asked if anybody had tried using the RSpec stories framework on a project yet. I considered using it for a Selenium-based acceptance test suite, but decided not to. Here is my response to the mailing list.

I considered switching to the RSpec stories framework at [client name removed], but I have one big lingering issue with doing it.

How well do acceptance criteria on a story correlate to focused selenium-based acceptance tests?

Often I need several selenium tests to cover one acceptance criteria on a story. Other times, a couple acceptance criteria can be covered in a single test, although it is certainly not as common as having multiple tests for a single criteria.

There's a couple scenarios there with using the story runner.

(1) Automated acceptance tests that correspond to the exact acceptance criteria from a story.
(2) Automated acceptance tests that don't correspond exactly to the acceptance criteria from the story, but are more suited to automated testing, written in a given/when/then style.

Regarding (2), I mostly consider a test name/description a comment. Given/when/then can be inferred from the test implementation. Given = setup, when = action, then = assertions. So as far as leaving a comment on the test to perhaps provide a little more insight into intent, describe/it seems sufficient.

Regarding (1), I like the idea of having traceability from a test to an acceptance criteria. But I feel acceptance criteria on a story card often do not correspond well with the tests that need to be written to verify the behavior. That may reflect on the quality of the acceptance criteria, but I'm not convinced they should be the same.

Outside of this issue around acceptance criteria, I personally don't like how much the using the story framework fragments the test implementation. I also question the reusability of a template "given", "when", or "then."

I would like to try using the story runner, but it doesn't seem any more beneficial than using describe/it.

Using DRb to Preserve a SeleniumDriver

Dan Manges — Thu, 14 Feb 2008 07:56:37 GMT

[Update] A Much Simpler Way

Philippe showed me a much simpler way of keeping the SeleniumDriver open. Start selenium like this:
selenium -browserSessionReuse -proxyInjectionMode

I'm leaving the original post here as an example of using DRb.

Original Post

Selenium is a great tool for web acceptance testing, but working on tests can be laborious. In addition to the general slowness of actually testing through the browser, starting a SeleniumDriver takes about 6 seconds on my MacBook.

SeleniumDriver Benchmark


require "rubygems"
gem "Selenium"
require "selenium"

benchmark = Benchmark.measure do
  driver = Selenium::SeleniumDriver.new(
    "localhost", 4444,
    "*firefox", "http://localhost:3000"
  )
  driver.start
  driver.stop
end
benchmark.to_s
#=> "  0.000000   0.000000   0.000000 (  6.294741)"

If the selenium driver could stay open between test runs, running a test could be much faster. Fortunately, DRb makes this easy. Here are the rough steps.

SeleniumDriver DRb Server

First, start a SeleniumDriver and place it in a DRb service.


require "rubygems"
gem "Selenium"
require "selenium"
require "drb"

SERVER = "druby://:51785"

driver = Selenium::SeleniumDriver.new(
 "localhost", 4444,
 "*firefox", "http://localhost:3000"
)
driver.start
DRb.start_service SERVER, driver
puts "Ready"
DRb.thread.join

The DRb.thread.join call at the end of this script means the script won't exit. Run it from a terminal, use Ctrl+C to stop it.

SeleniumDriver DRb Client

The next step is to use this instance when running tests. DRb provides a class that functions as a proxy to the object running in the server. In this case, that's the selenium driver.


DRb.start_service
driver = DRbObject.new(nil, SERVER)
class << driver
  # make sure type hits method_missing to delegate to driver
  undef_method :type
end

Using the DRbObject as a proxy to the SeleniumDriver requires hacking the type method to make sure it delegates properly.

SeleniumDriver with DRb Benchmark

Here's the benchmark for this version:


benchmark = Benchmark.measure do
  DRb.start_service
  driver = DRbObject.new(nil, SERVER)
  class << driver
    # make sure type hits method_missing to delegate to driver
    undef_method :type
  end
end
benchmark.to_s
#=> 0.000000   0.000000   0.000000 (  0.070634)

The time to start the driver is now negligible.

I've been using this for a few days, and it is working well. If you actually want to try this, here are a couple tweaks to the code that you'll want to make.

Stopping the Server

To stop the SeleniumDriver when stopping the process, wrap DRb.thread.join like this:


begin
  DRb.thread.join
rescue Interrupt
  begin
    puts "Stopping..."
    driver.stop
  rescue Exception
    puts "failed stopping selenium driver"
  end
end

Checking the Client Connection

DRbObject does not check the connection when it's first initialized. You may want to force it to check the connection by doing something like this:


begin
  DRb.start_service
  driver = DRbObject.new(nil, SERVER)
  driver.respond_to?(:anything?)
rescue DRb::DRbConnError
  # do something
  # fail over to non-DRb driver?
end

A call to respond_to? will check to see if the DRb server is available. You may want print out an informative message or fail over to using a non-DRb driver if it cannot connect.

Ruby Syntax Checker using Open3

Dan Manges — Thu, 27 Dec 2007 04:34:23 GMT

I recently needed to write code to check Ruby syntax. The Open3 library made it trivial. From the RDoc:

Open3 grants you access to stdin, stdout, and stderr when running another program.

Here's the code for the syntax checker. I also added an example of using Open3 with wc to print out how many lines of code the file contained.


require "open3"

class SyntaxChecker
  def self.check(ruby)
    Open3.popen3 "ruby -wc" do |stdin, stdout, stderr|
      stdin.write ruby
      stdin.close
      output = stdout.read
      errors = stderr.read
      SyntaxCheckResult.new(output.any? ? output : errors)
    end
  end
end

class SyntaxCheckResult
  def initialize(output)
    @valid = (output == "Syntax OK\n")
    @output = output
  end
  
  def line_of_error
    $1.to_i if @output =~ /^-:(\d+):/
  end
  
  def valid?
    @valid
  end
end

l, w, c = Open3.popen3 "wc" do |stdin, stdout, stderr|
  stdin.write File.read($0)
  stdin.close
  stdout.read.split
end
puts "This file contains #{l} lines, #{w} words, and #{c} characters."

if __FILE__ == $0
  require "test/unit"
  
  class SyntaxCheckerTest < Test::Unit::TestCase    
    def test_valid_syntax
      result = SyntaxChecker.check "this.is.valid.syntax"
      assert_equal true, result.valid?
    end
    
    def test_invalid_syntax
      result = SyntaxChecker.check "this.is -> not -> valid $ruby:syntax"
      assert_equal false, result.valid?
    end
    
    def test_invalid_syntax_line_number
      result = SyntaxChecker.check "line(1).is.okay\nline(2) is not :("
      assert_equal 2, result.line_of_error
    end
  end
end

Also see POpen4:

POpen4 provides the Rubyist a single API across platforms for executing a command in a child process with handles on stdout, stderr, stdin streams as well as access to the process ID and exit status.

Don't Be Clever

Dan Manges — Thu, 13 Dec 2007 04:18:43 GMT

Ryan Davis said his theme for 2007 is shaping up to be "don't be clever." However, it can be fun when pair programming to mess with your pair by writing some quick, clever code when he/she steps away. I was pairing on some code that needed reference to the days of the week, so I dropped this in:


DAYS_OF_THE_WEEK =
  (0..6).inject([]) { |a,i| [(Time.now + (i * 86400)).strftime("%A").downcase, *a] }

After my pair came back and reacted how I expected him to, I replaced it with the better version:


DAYS_OF_THE_WEEK = %w[monday tuesday wednesday thursday friday saturday sunday]

And, to flog them:

$ flog clever_days.rb 
Total score = 10.3653569644272

main#none: (10.4)
     3.3: assignment
     2.0: inject
     1.7: now
     1.7: *
     1.5: +
     1.3: strftime
     1.1: downcase
     1.0: branch
     0.5: lit_fixnum

And the second version:

$ flog better_days.rb 
Total score = 0

The flog score sums up the cost of cleverness well. For more on this theme, I recommend watching Ryan's RubyConf presentation.

Reading Gem Specifications

Dan Manges — Wed, 12 Dec 2007 03:02:35 GMT

When I was looking into the problem with installing deep_test with Rubygems 0.9.4, I wanted to see if the bug occurred with other gems. I noticed that the gem specification command will display the spec for a gem that is installed locally, but I couldn't figure out how to get it to display the specification from a gem file. I already had an rsync mirror of the gem repository, so I wanted to go through all the files to look for any gems built with 0.9.5 without a platform. Fortunately, Rubygems comes with a really easy way to read the specification from a gem file. Here's the script I used:


require "rubygems"
require "rubygems/package"

Dir["/Volumes/Backup/rubygems/*.gem"].each do |gem_file|
  begin
    Gem::Package.open(gem_file) do |gem|
      spec = gem.metadata
      if spec.platform == "" && spec.rubygems_version == "0.9.5"
        puts "#{spec.name} #{spec.version.version}"
      end
    end
  rescue
  end
end

Rubygems 0.9.5 Platform Bug

Dan Manges — Tue, 11 Dec 2007 04:29:15 GMT

If you're building a gem using Rubygems 0.9.5, make sure you have this line in your spec (assuming it's a pure-Ruby gem):

  specification = Gem::Specification.new do |s|
    s.platform = Gem::Platform::RUBY

Without it, the platform gets omitted and the gem cannot be installed from 0.9.4 clients. The gem shows up like this in the gem list:

2. deep_test 1.0.3 ()
3. deep_test 1.0.2 (ruby)
4. deep_test 1.0.1 (ruby)

And then Rubygems tries to download the gem with an extra hyphen at the end of the filename:
http://gems.rubyforge.org/gems/deep_test-1.0.3-.gem

I logged a defect and posted a message to ruby-talk. I haven't had time to look into the code to submitt a patch (assuming this is undesired behavior).

This happened to the following gems, and they will fail installing with 0.9.4:

addressable 1.0.1
aquarium 0.2.0
astro-algo 0.0.1
aurora 0.0.1
contextr 0.1.9
csspool 0.2.3
dango 0.0.38
dango 0.0.39
dango 0.1.0
dango_generator 0.0.38
dango_generator 0.0.39
dango_generator 0.1.0
deep_test 1.0.3
diy 1.0.1
el_req 0.0.1
faker 0.1.0
faker 0.2.0
faker 0.2.1
flac2mp3 0.2.0
gchart 0.1.0
gemsonrails 0.7.1
googlebase 0.1.1
googlereader 0.0.3
guessmethod 0.2.0
heel 0.6.0
oauth 0.1.1
polyglot 0.1.0
publisher 1.1.0
random_data 1.2.0
random_data 1.2.1
rawdio 0.1.0
roo 0.7.0
ruby-libtommath 0.41.0
rutema 0.4.1
rutema 0.4.2
sapo 0.0.2
yelp 0.2.0
yelp 0.2.1

Install Multiple Versions of Ruby on Leopard

Dan Manges — Thu, 15 Nov 2007 06:00:00 GMT

I'm glad that Apple bundled Ruby (1.8.6) with Leopard, but I need 1.8.5 installed to ensure compatibility with some projects that are deployed on servers running 1.8.5. Not only do I need 1.8.5, but I need it installed at different patch levels. Here is how I set up OSX to have multiple versions of Ruby installed.

Download

The first step is to download the versions of Ruby you want to install from ftp://ftp.ruby-lang.org/pub/ruby/1.8/. The latest 1.8.5 release is ruby-1.8.5-p114.tar.gz, and may be sufficient unless you specifically want/need an older 1.8.5 release.

Install

Start by extracting the tarball you just downloaded:
tar zxvf ruby-1.8.5-p114.tar.gz

You can install Ruby in any directory you want to. I chose to put mine under /usr/local/ruby-<version>:
cd ./ruby-1.8.5-p114
./configure --prefix=/usr/local/ruby-1.8.5-p114
make
sudo make install

You can confirm the installation by checking the Ruby version:
/usr/local/ruby-1.8.5-p114/bin/ruby --version

symlink for default Ruby version

With multiple versions of Ruby, you'll want an easy way to switch between them. One way to accomplish this is to create a symlink to the "current" version:
sudo ln -s /usr/local/ruby-1.8.5-p114 /usr/local/ruby

To switch to a different version by default, all you have to do is update the /usr/local/ruby symlink. You can verify the version of Ruby the symlink is linking to by trying:
/usr/local/ruby/bin/ruby --version

symlink Leopard's version

I also created a symlink for 1.8.6 to the default Leopard install:
sudo ln -s /System/Library/Frameworks/Ruby.framework/Versions/Current/usr /usr/local/ruby-1.8.6

/usr/bin executables

Leopard has Ruby-related executables in /usr/bin symlinked to the executables from the pre-bundled install. We need to change those to be able to toggle the Ruby version. There are a couple ways this can be accomplished. It should be done for all Ruby executables (cap, erb, gem, irb, rake, rdoc, ri, and ruby).

One option is to remove those symlinks altogether, and then add /usr/local/ruby/bin to the $PATH. That could be done by simply removing them from /usr/bin:
sudo rm /usr/bin/ruby (for all the executables mentioned above)
And then adding this line to ~/.bash_login:
export PATH="$PATH:/usr/local/ruby/bin"

The second option is to change the symlinks to point to the executables in /usr/local/ruby/bin. This isn't as favorable because any executable that is installed from a gem will be placed in /usr/local/ruby/bin. Unless you have that directory in your path (as mentioned with the previous option), you'll need a symlink for each executable. I recommend going with the previous option for that reason. However, you still may want to symlink the primary executables (namely, the core ones mentioned above) so that if your shell login script gets messed up, ruby, irb, gem, etc. will still be available.

alias

You may want to set up some aliases to make using and switching between Ruby versions simpler. These could go in ~/.bash_login. Here are some examples:

For executing a specific ruby, gem, or rake:
alias ruby186=/usr/local/ruby-1.8.6/bin/ruby
alias rake186=/usr/local/ruby-1.8.6/bin/rake
alias gem186=/usr/local/ruby-1.8.6/bin/gem

alias ruby185=/usr/local/ruby-1.8.5-p114/bin/ruby
alias rake185=/usr/local/ruby-1.8.5-p114/bin/rake
alias gem185=/usr/local/ruby-1.8.5-p114/bin/gem

For switching the default symlink:
alias use_ruby_186='sudo ln -fhs /usr/local/ruby-1.8.6 /usr/local/ruby'
alias use_ruby_185='sudo ln -fhs /usr/local/ruby-1.8.5-p114 /usr/local/ruby'

Rubygems

The last thing to do is to install Rubygems. Each Ruby installation will have its own copy of gems. You can download the latest version of of Rubygems from the Rubyforge project page. After downloading, extract the archive, switch your Ruby version, and run setup.rb:
tar zxvf rubygems-0.9.4.tgz
cd rubygems-0.9.4
use_ruby_185 (from alias)
sudo ruby setup.rb

Now you'll be able to install gems as normal using the gem command. Make sure you followed the steps with the /usr/bin executables so gem isn't always pointing to the 1.8.6 installation.

This should be everything you need to do to have multiple versions of Ruby available. I'll be writing an entry soon on how to take advantage of multiple installations to run test suites.

Debugging Rails Integration Tests

Dan Manges — Fri, 12 Oct 2007 05:00:00 GMT

Rails integration tests can be difficult to debug. The tests are usually coarse grained, which makes isolating the cause of failure difficult. A test to simply make sure a page is working (smoke test) might look like this:

def test_get_show_user_url
  get show_user_url(User.find(:first))
  assert_response :success
end

This test is sufficient to make sure M, V, and C are all playing nice together. However, if an exception is raised, the output from the test is this:

Expected response to be a <:success>, but was <500>

Clearly not helpful in knowing what went wrong.

The easiest thing to do is display the rendered output from the 500:

def test_get_show_user_url
  get show_user_url(User.find(:first))
  assert_response :success, @response.body
end

Here, @response.body is the message for the assertion, and is only displayed if the response is not success. This provides output that helps debug test failures, but the output is really noisy. It's the HTML page that you normally see in your browser with a 500, and contains several stack traces and other debugging info. It's great in the browser, not so great in the console.

The best way to make the failures easy to debug is to let the exception be rescued by the test instead of by the controller. To do this, you need to tell the controller and the dispatcher not to rescue:

ActionController::Base.class_eval do
  def perform_action
    perform_action_without_rescue
  end
end

Dispatcher.class_eval do
  def self.failsafe_response(output, status, exception = nil)
    raise exception
  end
end

This code should go in the test helper for your test suite. Conventionally this will be: test/integration/integration_test_helper.rb

DeepTest Now Available

Dan Manges — Wed, 12 Sep 2007 05:00:00 GMT

DeepTest is now available. Use it to run your test suite nearly twice as fast

Installation

gem install deep_test

Usage

DeepTest::TestTask.new "task_name" do |t|
  t.pattern = "test/**/*_test.rb"
  t.processes = 2 # optional, defaults to 2
end

More Information

For other details you need to know, check out something nimble.