How I made Autotest RedGreen and Growl party together

Giovanni Intini — Sat, 31 May 2008 11:22:19 +0000

If you’re like me and like autotest as a sort of private continous integration system, and if you like pretty output, you will probably have used some kind of autotest + redgreen and/or growl.

Unfortunately I had strange quirks in my growl notifications. Sometimes they worked, sometimes they didn’t (I was using the standard :ran_command autotest hook at the time), so I switched to the newer :red and :green hooks, and only worsened the problem. No matter what the test output was, I always got a green notification.

I was able to trace the problem to the redgreen gem. Its colorized output wasn’t being recognized correctly by autotest and it kept thinking everything was ok.

A little ruby fiddling and this is my new improved (and working!) .autotest file:

# -*- ruby -*-
 
module Autotest::RedGreen
  Autotest.send(:alias_method, :real_ruby, :ruby)
  Autotest.send(:define_method, :ruby) do |*args|
      real_ruby + %[ -rrubygems -e "require 'redgreen'" ] 
  end
 
  # Clean the output so other modules can work correctly
  Autotest.add_hook :ran_command do |at|
    at.results.each do |r|
      r.gsub!("\033[31m", "")
      r.gsub!("\033[32m", "")
      r.gsub!("\033[33m", "")
      r.gsub!("\033[0m", "")
    end
  end
end
 
module Autotest::Growl
  AUTOTEST_IMAGE_ROOT = "~/.autotest_images"
 
  def self.growl(title, msg, img, pri=0, sticky="")
    system "growlnotify -n autotest --image #{img} -p #{pri} -m '#{msg.inspect} #{title}' #{sticky}"
  end
 
  Autotest.add_hook :red do |at|
    growl("FAIL", "#{get_results(at)}", "#{AUTOTEST_IMAGE_ROOT}/fail.png", 2)
  end
 
  Autotest.add_hook :green do |at|
    growl("Pass", "#{get_results(at)}", "#{AUTOTEST_IMAGE_ROOT}/pass.png")
  end
 
  private
  def self.get_results(at)
    results = [at.results].flatten.join("\n")
 
    if results.include? 'tests'
      output = results.slice(/(\d+)\s+tests?,\s*(\d+)\s+assertions?,\s*(\d+)\s+failures?(,\s*(\d+)\s+errors)?/)
    else
      output = results.slice(/(\d+)\s+examples?,\s*(\d+)\s+failures?(,\s*(\d+)\s+not implemented)?/)
    end
    output
  end
end
 
# Esclusioni
Autotest.add_hook :initialize do |at|
  %w{.hg .git .svn stories tmtags Rakefile Capfile README spec/spec.opts spec/rcov.opts vendor/gems autotest svn-commit .DS_Store }.each do |exception|
    at.add_exception(exception)
  end
 
  at.add_mapping(/spec\/defaults.rb/) do |f, _|
    at.files_matching %r%^spec/(controllers|helpers|lib|models|views)/.*\.rb$%
  end
end

Our setup had apache as webserver so I don’t need any special code to restart the application. In addition to this recipe, made to deploy to production I also wrote a couple of tasks that shine during development.

Drupal has the problem of storing most of the important stuff in the database, and if you do local development, showing the status of the work to your clients can be a chore. The following tasks allow you to easily dump the development db and import the dump to the staging server to show your progresses to your customers and allow testing the site:

# Callbacks
before 'deploy:start', 'drupal:db:import:production'
 
before 'deploy:restart', 'mikamai:permissions:fix', 'mikamai:production:symlink', 'drupal:configure:production'
before 'deploy:start', 'mikamai:permissions:fix', 'mikamai:production:symlink', 'drupal:configure:production'
before 'deploy:cold', 'drupal:db:dump:development'
 
# DB Stuff
 
set :mysqldump, "/opt/local/bin/mysqldump5" # your path to mysqldump
# local db credentials
set :local_db_user, "root"
set :local_db_password, ""
set :local_db_name, "database"
# remote db credentials
set :db_user, "user"
set :db_password, "secret"
set :db_name, "database"
 
namespace :drupal do
 
  namespace :configure do
    task :production do
      sudo "cp #{latest_release}/sites/default/settings.production.php #{latest_release}/sites/default/settings.php"
    end
 
    task :development do
      sudo "cp #{latest_release}/sites/default/settings.development.php #{latest_release}/sites/default/settings.php"
    end
  end
 
  namespace :db do
    namespace :dump do
      task :development do
        raise RuntimeError.new("failed dump") unless system "#{mysqldump} -u #{local_db_user} --password=#{local_db_password} #{local_db_name} > dump.sql"
      end
    end
 
    namespace :import do
      task :production do
        ENV["FILES"] = "dump.sql"
        deploy::upload
        run "mysql -u #{db_user} --password=#{db_password} #{db_name} < #{latest_release}/dump.sql"
      end
    end
  end
end

VBLiteUnit saved my life

Giovanni Intini — Mon, 16 Jul 2007 08:30:56 +0000

I want to personally thank the guys at VBLiteUnit. Without their unit testing framework I wouldn’t have been able to catch and squash a bug in a vba product I coded for a client some time ago.

The bug was stupid but difficult to catch because it altered a few record every ten or so in a long query that is used to pay people, so some people were getting double pay! Good for them but not for my client

I had never done testing in vba before so I started to write my own testing routines, then I decided to check google again for free testing frameworks for vba and found VBLiteUnit.

62 asserts later the bug was found and killed without any remorse whatsoever

Test Driven RJS with ARTS

Giovanni Intini — Wed, 04 Apr 2007 10:40:52 +0000

If you’re like me, you like writing tests for your code. Writing tests is a nice thing to do and saves you a lot of headaches.

Writing tests for Ruby on Rails is really simple, with the wonderful testing framework built in Rails, but things become less ideal when you need to write tests for your RJS code.

This morning I wanted to test the following snippet:

def add_file_field
  render :update do |page|
    page.remove "link_to_add_#{params[:attachment_type]}"
    page.insert_html :bottom,
                     params[:attachment_type],
                     :partial => "#{params[:attachment_type]}_file_field", 
                     :locals => {:index => params[:index].to_i}
  end
end

But the test was failing and I didn’t know why. The ARTS Plugin came to the rescue, allowing me to test the rjs response:

  def test_add_file_field
    xhr(:get, :add_file_field, :index => 1, :attachment_type => "plan")
    assert_response :success
    assert_rjs :remove, "link_to_add_plan"
    # more code here...
  end

Unfortunately that didn’t help with my problem since the cause was not the RJS, I was simply forgetting to login in my setup method

A Tempest of Thoughts » Testing

How I made Autotest RedGreen and Growl party together

VBLiteUnit saved my life

Test Driven RJS with ARTS