Clever::Tagline::Pending

The release of RSpec 0.9.4 can be considered a landmark release of sorts. With the inclusion of Spec::Ui 0.2.0, RSpec can now perform functional testing of web applications within a browser. Out of the box support is limited to Watir/Internet Explorer for now as the Selenium RC custom matchers are not implemented yet. includes WATIR/Windows and Watirsafari/OSX. The custom matchers for Selenium RC are not implemented yet but its certainly possible to use Selenium with Spec::Ui, it just won’t read as nicely compared to WATIR. Spec::Ui also comes with a custom result formatter that packages a screenshot of the browser on spec failure, along with its HTML source in the report.

To use Watirsafari in your functional specs, you’ll need to install the gem for it: gem install watirsafari

spec_helper.rb should be updated to include the snippet below (code lifted from the original release announcement):

[ruby]
Spec::Runner.configure do |config|
config.include Spec::Matchers::Watir
end
[/ruby]

The specification will need before and after blocks like this:
[ruby]
before(:all) do
@browser = Watir::Browser.new
end

after(:each) do
# This is needed to make screenshots work
Spec::Ui::ScreenshotFormatter.browser = @browser
end

after(:all) do
@browser.kill! rescue nil
end
[/ruby]

There are a lot more useful information available in the examples supplied with Spec::Ui. Take a look at the samples to get up and running.

Update
My thanks to Aslak Hellesoy for correcting me on support for WATIR and Selenium.

The next singapore.rb meeting will be held on the 19th of April 2007 in the Central Lending Library. The National Library Board of Singapore has kindly provided the use of one of their meeting rooms (complete with WIFI). The (tentative) agenda for the meeting is as follows:

7:00pm Rails Plugins Showcase: Dead simple AJAX and Form testing in Rails – Choon Keat
7:30pm FxRuby and ScreenSvr – Sausheong
8:00pm Q&A, discussions
8:30pm End of meeting

My thanks goes out to the NLB’s Ivan Chew for facilitating the use of NLB facilities for a trial session, as well as to Choon Keat and Sausheong for making the presentations.

The Rails Podcast has an excellent interview with Josh Shairbaum and Dan Manges from JP Morgan on using Rails in the enterprise. Do check it out if you’re at all interested in introducting Ruby/Rails to your particular company.

Listening to Josh and Dan made me realise that I’m quite fortunate to be working in a company where there are no corporate traditions to follow when it comes to technology. I’ve developed 2 applications for use by staff and clients alike so far and they’re both powered by Rails. Being the sole developer in my company, Rails is a perfect fit and this combination has shown its worth.

Josh mentioned that his development team of 3 got Rails in the door by using it to develop a reporting application, an app where the implementing technology was not a big issue with corporate managers. By having the reporting application running AND available to end users within 1.5 months demonstrated the productivity gains that can be achieved by Rails. A lot of evangelizing and demonstrations were done to help their cause too. I think that they benefited a fair bit from having key people in other functional units willing to give Rails a try, even though it required them to risk doing something that’s new and by corporate definition, risky.

It’s encouraging to listen to them and their passion for Rails was apparent in the way they talked about and how they dealt with people who did not understand what it was.

I’ve started using RSpec in my Rails projects. Besides serving the purposes of testing my application, it has also become an extremely useful design tool. Comparing the DSLs for Test::Unit and RSpec, the latter expresses the intention of the tests much more clearly and quickly. Luke Redpath does a great job of explaining the basics of Behaviour Driven Development using RSpec on Rails. Its a must read if you’re interested in exploring BDD for your Rails development.

Technorati Tags: Rails, Ruby, Testing

Rick Olsen, a member of the Rails core team has a good writeup on working with ActiveResource. It seems that Beast is taking advantage of ARes to provide a RESTful API while keeping all the heavy lifting transparent to the user of the resource.

The documentation on ActiveResource is really scarce at the moment and posts like Rick’s are hugely useful to Rails developers who are looking to leverage ARes in their applications. Speaking on which, I would be refactoring an internal app used within my agency for ARes soon. I just have to implement the remaining user stories and take it to 1.0 first.

More on that as I get deeper into development.

singapore.rb aka Singapore Ruby Brigade is meeting next wednesday, 6th Sept 2006. We’ll be at the City Hall Starbucks joint around 7pm, so drop by and say hello if you’re in the area.

The Rails core team released 1.1.6 of the framework today, a day after 1.1.5 was released. This was to fix a serious vulnerability in the Routes module. The core team has been extremely prompt in publicising the hole and in releasing fixes.

However(you know there had to be one), I take issue with how the first fix release (1.1.5) was handled. It appears that this release did not fully rectify the problem, hence the need for 1.1.6. While DHH revealed the reasons for 1.1.5, he did not detail exactly what was wrong, opting for a security through obscurity approach.

In retrospect, a full disclosure policy would have been a better move. This would have given developers more information in deciding whether to shut down their sites, in view of the implications(data loss/theft et al) of having it compromised.

That said, if you’re running a rails web application in the wild, UPGRADE NOW.

EDIT: mixed up my rails versions, doh!

The newly minted singapore.rb will be meeting this Wednesday in the city area. This will be the first meeting between the members so it would be fun matching the messages in the Ruby and Rails list to faces.

Zed Shaw shares his insights and experiences in building Mongrel.

I wanted to be able to have my testing regime automatically create files associated with model fixtures defined in the fixture files. Coincidentally, I’m using Sebastien Kanthak’s file_column plugin for managing files in models.

After looking at the Fixture class and the FileColumn module, I realised that I needed a way to store the model attribute(s) that were passed in the call to file_column. What FileColumn did was create the methods according to the attribute passed into the method but the attribute itself is not actually stored anywhere.

Time to extend FileColumn:

[ruby]require File.join(RAILS_ROOT, ‘vendor’, ‘plugins’, ‘file_column’, ‘lib’, ‘file_column’)

module FileColumn
module ClassMethods
@@file_column_attributes = {}
alias :aliased_file_column :file_column
def file_column(attr, options = {})
aliased_file_column(attr, options)
klass = self.name.constantize
@@file_column_attributes[klass] ||= []
@@file_column_attributes[klass] << attr
end

def file_attributes
@@file_column_attributes[self.name.constantize]
end
end
end[/ruby]

As the name implies, the methods in ClassMethods are class methods on the including class. So in order to store the file_column attributes, we need a class variable, @@file_column_attributes. This variable is a hash with the model class name as the key and an array containing the attributes.I’ll also implement a class method so that I’ll be able to do Model.file_attributes and know what attributes have been file_columnised.

Next, we’ll need to change the way fixtures are populated to the test database. This involves extending the Fixtures class.

We’ll do this in test_helper.rb

[ruby]
require ‘fileutils’
class Fixtures
SAMPLE_FILE = File.join(Test::Unit::TestCase.fixture_path, ‘files’, ’sample.pdf’)
include FileUtils

alias riginal_insert_fixtures :insert_fixtures

def insert_fixtures
original_insert_fixtures
create_files(@class_name, values) unless @class_name.constantize.file_attributes.nil?
rescue NameError
# workaround for HABTM fixtures
end

def create_files(klass, values)
model_dir = File.join(Test::Unit::TestCase.fixture_path, ‘media’, ‘uploads’, klass.downcase)
values.each do |fixture|
klass.constantize.file_attributes.each do |attr|
create_file(fixture, attr, model_dir) unless attr.nil?
end
end
def create_file(fixture, attribute, parent_dir)
attribute = attr.to_s
dest_dir = mkpath(File.join(parent_dir, attribute, fixture['id'].to_s))
file_dest = File.join(dest_dir, fixture[attribute])
cp(SAMPLE_FILE, file_dest) unless fixture[attribute].nil? or File.exists?(file_dest)
end
end
[/ruby]

The extended insert_fixtures method first invokes original_insert_fixtures, then checks whether the model has any file_column attributes. If it does, the files defined in the fixtures will be created if they don’t already exist.

EDIT: Running functional tests with rake test:functionals fails miserably even though running the tests individually is just fine.