One of the first steps was to use a continuous integration server. I was actually surprised so few existed and the choice for CruiseControl(CC) was a quick one. This pretty piece of software did not support Git out of the box but there exists a GitHub branch incorporating this functionality. What is even better is this post which explains how to use it! So I won’t go into the nitty gritty details, what I will do is point out some pit falls and how to make CruiseControl play nice with RSpec. Which it also does not support out of the box but which is really easy.

Install CC as per previously mentioned post. What threw me off where the site_config.rb and the cruise_config.rb I got the (wrong) impression that these files lived in the root directory of the CC install. This is not the case. When installing CC it, by default, creates a directory ~/.cruise which holds your projects. It is here where the site_config.rb file lives. And this is the file to configure ActionMailer! And in the directory ~/.cruise/projects/MyProject the other file can be found in which to configure the people who need to receive emails when the build breaks.

When CC builds a project it just runs some Rake tasks, one of which is cruise. Getting CC to use RSpec is as simple a overwriting this task! This is what I gleaned from other posts:

desc "Task to do some preparations for CruiseControl"
task :prepare do
RAILS_ENV = 'test'
end

desc "Task for CruiseControl.rb, automatically picked up"
task :cruise => [:prepare, "db:migrate", "spec"] do

end

The first task is to make sure the test environment is used which is really what you want in a situation like this.

The next step would be to produce something more readable than the dump of the log file with the results of the ran RSpecs.

The task at hand was to augment the users in the system with roles. We had a column in the Members table which made a member a manager or not(boolean). This information is now extracted to a roles table (we are using RoleRequirement). It is now possible to assign many different roles to each member.

The migration I wrote at first looked something like this:

def self.up
r = Role.new(:name => "manager"
r.save
remove_column :members, :manager
managers = Member.find_all_by_manager(true)
managers.each do |manager|
manager.roles << r
manager.save
end
end

However this migration failed on the manager.save, complaining that the column manager on the table members no longer existed. And it didn’t of course. The column had just been removed! I figured that the attributes in the manager objects still contained the :manager => true key-value pair. So I deleted that but the error persisted. Which makes sense when I thought about it. The migration loaded the Rails framework with all inferred classes. One of these classes was the Member class which contained at the time of loading still a manager field. Trying to save the member without one of the attributes causes an error. Reloading framework seemed a bit overkill as well.

In the end the solution was, as most of the time, deceptively simple. Remove the column at the end of the migration!

def self.up
r = Role.new(:name => "manager")
r.save
managers = Member.find_all_by_manager(true)
managers.each do |manager|
manager.roles << r
manager.save
end
remove_column :members, :manager
end

But how do you test your migration? I took a stab at this in the form of an RSpec test:

describe Member, "should migrate properly" do
it "should migrate correctly from a column manager to a role manager" do

`rake db:drop`
`rake db:create`
`rake db:migrate VERSION=59`
m1 = Member.new(:manager => true)
m1.save_with_validation(false)
m2 = Member.new(:manager => true)
m2.save_with_validation(false)
m3 = Member.new(:manager => true)
m3.save_with_validation(false)
`rake db:migrate VERSION=60`
Member.find(m1.id).has_role ?("manager").should be_true
Member.find(m2.id).has_role?("manager").should be_true
Member.find(m3.id).has_role?("manager").should be_true
end
end

But this does not work yielding a MySQL timeout. This has to do with the fact that all tests are run in transaction mode preventing other database changes during the tests. This particular test waits for the lock to be released which never happens and thus times out.

I have yet to figure out how to do this, but I think this is really important! I would love to be able to test my migrations as these migrations manipulate live data which can not be lost. Any suggestions are welcome.

What you really want is to be able to background tasks and be done with it! For this there are many options. Unfortunately. But I believe the two candidates worth looking at are:

• beanstalkd
• backgroundrb

Beanstalkd is being used on Facebook(need I say more?). BackgroundRB enjoys more attention and has recently been rewritten and thus presumably increased in quality. The first is not as tightly coupled with Rails as the latter but that can be amended with a plugin.

Then there is the matter of compiling beanstalkd… That was no fun at all. Well maybe I made it too hard for my self and I did not exactly knew how to manipulate ‘make’. But I wanted the latest version(0.11) of beanstalkd and MacPorts only had 0.9 in stock. So I downloaded the source, followed the readme and hit make. Of course that didn’t fly. I needed to point the makefile to the correct lib directory. Long story short, I did install beanstalkd through port and took the makefile from that install and patched the makefile in the source download. Here is the patched makefile. This worked like a charm! However this made me a bit concerned how up to date the packages on our Debian staging server were. It turned out that I needed to install both the dependencies and the actual beanstalkd from source. I’d prefer gems then.

For more information on beanstalkd I gladly refer to this blog post as I decided after this ordeal that I would go forward with backgroundrb. This decision was mainly based on the better logging abilities of backgroundrb and the from source install as opposed to some gems.

A parting thought; look at the footer of backgroundrb’s website. Notice the link called Ginger Ninja? Click it. I think it’s at least weird and perhaps doggy.

response.should have_rjs(:chained_replace_html, "some_id") do
response.should have_text(/some random text/)
end

The response object should have an RJS object but what type? According to the assert_select_rjs method, which the have_rjs method wraps, there are only a hand full of these types but apparently not all of them are listed. As I found out when my inline RJS:

render :update do |page|
page[update_div].update(text)
end

None of the mentioned types responded correctly. But I noticed that the blog post mentioned earlier used an other type. Browsing through the source code of assert_select_rjs I found my missing type: chained_replace_html. Hooray! Everything worked fine and dandy from there on.

One last hiccup was that code in the block passed to the have_rjs method does not scope by default the response.should directive, so this is wrong:

response.should have_rjs(:chained_replace_html, "some_id") do
have_text(/some random text/)
end

Obviously.

before(:each) do
klass = Class.new { include FicklePricing }
@foo = klass.new
@foo.stub!(:id).and_return(1)
end

In this case we have created a class with does nothing but to include our module. And this almost empty class can by instantiated and used in this specs. Trivial example:

it "should respond_to price method" do
@item.should respond_to(:get_price)
end

before(:each) do
ActionMailer::Base.delivery_method = :test
ActionMailer::Base.perform_deliveries = true
ActionMailer::Base.deliveries = []
end

This before block set the method for delivery method to :test. Normally it default to :smtp and an other possibility is :sendmail. The second directive tells ActionMailer to actually send the emails(who would have guessed?). The deliveries array keeps track of every email sent.

Now you can just send your email as you usually would:

mail = Notifications.deliver_some_random_email("name")
ActionMailer::Base.deliveries.size.should == 1
mail.body.should =~ /name/

Rock on RSpec.

class Foo
  def bar
    text = 'fake' #assigns a variable 'text'
    text.gsub!() #changes the variable 'text'
  end

  def bla
    text.gsub!() #does not find a variable 'text', then searches for a method 'text'(and fails in this case)
  end
end

So if you want to change a field in an ActiveRecord model you need to tell Ruby not to create a local variable but to use the generated setter method.

class Foo < AR:B
  def bar
    self.text = 'fake' #assigns the field 'text'
    text.gsub!() #changes the variable 'text'
  end
end

copy = Project.new
p = Project.find(:first)
copy.title = p.title
copy.description = p.description
p.members.each do |member|
  copy.members.build(:name => member.name, :function => member.function)
end

This is prone to errors not to mention ugly(and a lot of dumb work).

So I figured I’d write something better. This was quickly done:

class Project < AR:B
  cattr_accessor :non_duplicatable_columns
  non_duplicatable_columns = [primary_key, 'created_at', 'updated_at','created_on', 'updated_on'] + column_names.select {|column_name| column_name =~ /_id$/}      

  def copy
    copy_columns = self.class.column_names - self.class.non_duplicatable_columns
    a = Hash.new
    copy_columns.each {|cc| a[cc] = self.send(cc) }
    clone = Project.create(a)
  end
end

But I needed this piece of functionality in several models. So what’s a good programmer to do? Refactor the code into a module of course! But there I hit some snags. The method cattr_accessor, for example, is a bit of a strange beast. It is not documented but is should be read like ‘class attribute accessor’. The method creates class instance methods. This is something different from instance methods which you usually use. Instance methods are callable on an object which is instance of a class.

p = Project.new #class instance method
p.copy #instance method

Defining class instance methods goes with the

self

keyword. It reminded me of the Java static keyword.

def self.foo
  #do something, can be called as: FullClassName.foo
end

Keep the eye on the ball here, self points to the object on which this method is called. When defining the copy method the method column_names is called but this is a class instance method from the class subclassing AR:B. So the objects looks at itself, asks who the fathering class is and calls the desired method from that class.

The method

cattr_accessor

can no longer float freely in the class definition. It needs a container as the module is read at the moment the Rails stack is initialize and at that point the module is not necessarily hooked into a class in which a cattr_accessor makes sense. Luckily the module “http://ruby-doc.org/core/classes/Module.html”:Module defines a method included which is called whenever the module is, well, included. Using this we can still define the

non_duplicatable_columns

on a per model basis.

Finalized the module looks like this(stored in lib/duplicatable.rb):

module Duplicatable

  def Duplicatable.included(base)
    base.cattr_accessor :non_duplicatable_columns
    base.non_duplicatable_columns = [base.primary_key, 'created_at', 'updated_at','created_on', 'updated_on'] + base.column_names.select {|column_name| column_name =~ /_id$/}
  end

  def copy
    copy_columns = self.class.column_names - self.class.non_duplicatable_columns
    a = Hash.new
    copy_columns.each {|cc| a[cc] = self.send(cc) }
    clone = self.class.create(a)
  end
end

And a simple include Duplicatable adds all its functionality to a model.
Why not use a super class here? That would require calling a initialize function(to set the non_duplicatable_columns) in each model with would extend this super class. Which would result in more code and thus more places where this can break.

Last weekend I picked up a pet project which a colleague and I came up with. Nothing difficult and we figured we could get this done within the week. Boy was I wrong. Setting the whole thing up took me the better part of the day. Of course partially due to my own inexperience but the fact that I was using Edge for everything didn’t help.

I’ll skip all the things which went horribly wrong, this is what I _should_ have done:

$ rails new_prj
$ cd new_prj
$ piston import http://dev.rubyonrails.org/svn/rails/trunk vendor/rails
$ piston import svn://rubyforge.org/var/svn/rspec/trunk/rspec vendor/plugins/rspec
$ piston import svn://rubyforge.org/var/svn/rspec/trunk/rspec_on_rails vendor/plugins/rspec_on_rails
$ ./script/generate rspec

Don’t try to freeze rails using rake rails:freeze:edge. This leads to pain and the absence of a framework dependency causing the ./script/server command to fail.
Don’t try to use the current release of RSpec in combination with the edge version of Rails. This again leads to suffering and mysteriously failing tests.
Don’t forget that running ./script/generate rspec_model is not enough to get the entire RSpec framework to behave. It’ll work to some degree but has some crucial functionality missing. For example the ./script/spec command is missing.
Don’t expect Restful authentication to play nice with RSpec through Vaporbase’s spec files. Don’t get me wrong the guys of Vaporbase did a great job it just didn’t work for me. The class UserNotifier should be UserMailer in my instance and the protected helper methods in the sessions_controller_spec.rb are ran by rspec throwing weird errors. So these should be moved to the spec_helper.rb file.

As a final bonus, ever wanted to spec a single file?

$ ./script/spec spec/controllers/foo_controller_spec.rb --color -b