Kerry Buckley

For ages I've been getting an intermittent problem with RSpec, where occasionally I'd see the following error on a model spec:

You have to declare the controller name in controller specs. For example:
describe "The ExampleController" do
controller_name "example" #invokes the ExampleController
end

The problem seemed to depend on which order the specs were run in, and for rake it could be avoided by removing --loadby mtime --reverse from spec.opts. It was a real pain with autotest though, and today (my original plan of "wait for RSpec 1.1 and hope it goes away" having failed) I finally got round to looking into it properly.

It seemed that the error was being triggered by the rather unpleasant code I wrote a while ago to simplify testing of model validation. Digging into the RSpec source to see what was happening, I found that that error message only gets returned when (as you'd expect) you don't declare the controller name in a controller spec (specifically in an instance of Spec::Rails::Example::ControllerExampleGroup). The code that decides what type of example group to create lives in Spec::DSL::BehaviourFactory, and according to its specs, there are two methods it uses to figure out what type of spec it's looking at:

I began to suspect that the problem was caused by the fact that my specify_attributes method wasn't declared in a file in spec/models, so I thought I'd try specifying the type explicitly. So instead of this:

I changed it to this:

Sure enough, it worked! Not sure whether anyone else is likely to see the same problem (unless they're foolish enough to use my validation spec code), but hopefully if you do, a Google search will bring up this post and it might point you in the right direction.

This clip [MP3, 57s] from a Rails Envy podcast made me laugh. It's referring to Charles Nutter's recent musings on whether werewolf is killing the conference hackfest.

Incidentally, how often do you get the chance to Google for "nutter werewolf"?

Technorati Tags: rails envy, werewolf

I Spent some time yesterday tracking down a bizarre bug which was causing some of our Selenium tests to fail. Watching the browser running the tests, I could see that occasionally a page would fail to render, with an "invalid argument" error and a stack trace. The line in question was an <%= end_form_tag %> in a layout. The strange thing was, it didn't display the same behaviour when I ran the single failing test on its own, or when I viewed the page myself.

Or at least, I thought it didn't. Because it seemed intermittent, I tried reloading the page a few times, and sure enough, the error appeared. Once. Then the page reloaded successfully six times, before failing again. This was completely repeatable – six times OK; one stack trace. Regular as clockwork.

Completely stumped, I thought I might as well at least replace the deprecated <%= start_form_tag %> … <%= end_form_tag %> with <% form_tag do %> … <% end %>, and lo and behold, that fixed it.

Unfortunately, I have no idea why. An imaginary prize to whoever can explain it!

As far as I can tell, this is the correct way to do case-insensitive string comparison in Ruby:

That's so ugly, it almost looks like Java. Actually, it's worse than Java, which has String#equalsIgnoreCase.

[Update] The story runner is now included in the 1.1 release of RSpec, so a lot of the hackery mentioned below is no longer required. See http://rspec.info/ for details.

Background

A while ago I cobbled together some code to drive Selenium from Exactor (which was the acceptance testing framework we were using at the time). That project was offshored shortly afterwards, and I'm pretty sure Selenium never actually got integrated into the build (sneaking a peek at the continuous integration server reveals that even the pre-Selenium acceptance test build hasn't run successfully for months), but I was convinced of the value of Selenium for testing non-trivial web applications.

On my next project (the Web21C SDK portal) we used Selenium on Rails heavily for automated acceptance testing. This worked well, although the fact that the tests are deployed with the application limits what you can do – you can't interrogate the database after a test, for example, or dynamically set up stubs for systems you interface with (unless you also deploy the stubs as part of the application, and drive them from the browser).

With Mojo there's an additional complication: as well as being accessible through a browser, most functionality is also available as a RESTful API, using digest-based authentication. To keep our acceptance tests in one place, we wanted to be able to drive a browser using Selenium, alongside other tests which talked to the server directly. The obvious answer was to use Selenium Remote Control, and I also liked the look of RBehave, which has now been incorporated into RSpec (but not released yet).

The RSpec story runner

The story runner in the upcoming release of RSpec is an evolution of Dan North's RBehave, which in turn is based on JBehave (from the same author). In the past couple of weeks, David Chelimsky has done some excellent work on extracting the text of stories from the code, leading to the plain text story runner.

Read on for the gory details of my solution to running Selenium tests from the story runner.
Read the rest of this entry »

I was quite excited to see the announcement of improved Ruby and Rails support in Leopard, and one of the first things I did after upgrading was to delete my MacPorts installations of Ruby and RubyGems, and try using the built-in ones instead.

For a while, all seemed well. The milk was cold, the food stayed fresh, my specs still passed, my Rails projects still worked, and even the light worked when you opened the door.

But then the trouble started.

Firstly I tried updating and installing gems while behind a firewall. The gem command completely ignored my http_proxy setting, and when I explicitly provided the proxy using -p, I got this error:

ERROR:  While executing gem ... (NoMethodError)
    undefined method `[]=' for #

I worked round this by downloading the gems manually and installing the local copies (despite this being a pain, especially when there are dependencies).

I then tried using gemsonrails to freeze some gems, and it got confused by the fact that Leopard stores built-in gems separately from user-installed ones. Thinking about it, if I'd successfully frozen the gem, it might have turned out to have been tweaked in some Mac-specific way and broken on other platforms.

Forgetting about that issue, I carried on with other work for a while, then found that autotest wouldn't work, and mysteriously was trying to run something from /opt/local (where MacPorts install lived). Even after removing any gem-related scripts from /opt/local/bin, the problem persisted.

Oh well, looks like I'll be re-installing everything using MacPorts. I'm not sure whether all these problems are intrinsic to the Ruby installation that comes with the system, or whether some are caused by lingering remains of my MacPorts installation – I'd be interested to hear how others got on.

Technorati Tags: ruby, rails, mac, 10.5, leopard

From the list of new features coming in Rails 2.0:

It’ll probably come as no surprise that Rails has picked a side in the SOAP vs REST debate. Unless you absolutely have to use SOAP for integration purposes, we strongly discourage you from doing so.

def duck?
  respond_to? :quack
end

One of RSpec's many neat features is the ability to insert placeholder specs. These allow you to list a whole bunch of expected behaviour up front, without having to implement either the specs or the code, and without creating a huge swath of failing specs. All you need to do is omit the body of the specify or it block. Here's a trivial example:

$ spec -f s foo_spec.rb                     

The string 'foo'
- should be three characters long
- should be capitalised to 'Foo' (NOT IMPLEMENTED)

Finished in 0.011201 seconds

2 examples, 0 failures, 1 not implemented

Technorati Tags: ruby, rspec

I've recently jumped on the Facebook bandwagon. I can't be bothered to update two statuses (I rarely get round to it with one), so I was looking for a way to update my FaceBook status from Twitter. I installed the Twitter application in FaceBook, but that just displays the Twitter status separately.

It seemed that the only way to do it was to write a script to regularly check Twitter, and update FaceBook when it found a new Twitter message. I found a partial solution in PHP, but decided to roll my own in Ruby anyway.

It took a few hours longer than I expected (the documentation for Net::HTTP could be better), but I got there in the end. I now have the script below installed on my DreamHost account, and set to fire every minute via cron. It's not the prettiest code I've ever written, but it does the job. Feel free to borrow it if you think it'll be useful.

My reply:

Technorati Tags: facebook, twitter, ruby, mashup