Robby on Rails

This is inspired by a recent post by Seth Godin titled, Things you don’t understand, where he shared a list of things that he probably could understand if he put your mind to it, but doesn’t. I decided to post a list of five (5) things in response within the context of Ruby/Rails.

I’m really interested in various things but am really unable to prioritize them high enough to spend the time to understand them.

• RSpec User Stories
• Using Selenium with RSpec
• JQuery (Graeme speaks highly of it)
• JSSpec (BDD for Javascript)
• Using the Google Charts API with Rails

What about you? What’s your list of things that you’d like to understand more about?

A few weeks ago, I moved RubyURL from subversion to git. During that process, I decided to use my invite to GitHub and have decided to go ahead and open up the source code.

It’s currently a whopping 92 LOC with a 1:2.5 code to spec ratio. (I had a goal to keep is below 100 LOC)

• RubyURL on GitHub: http://github.com/robbyrussell/rubyurl
• Public Clone URL: git://github.com/robbyrussell/rubyurl.git

Feel free to grab it and help contribute. This has served almost 14 million redirects since August 2007 and is running on a Rails Boxcar.

To grab it with git.. run: git clone git://github.com/robbyrussell/rubyurl.git.

Feel free to submit tickets to the Rubyurl ticket system.

• http://planetargon.lighthouseapp.com/projects/4059-rubyurl

Enjoy!

UPDATE Ryan McGeary was kind enough to be the first person to help track down a bug and submit patches. :-)

I meant to work on this post… oh about 7 months ago.

Way back in January (7 months ago), Jamis Buck posted an article titled, Testing your views, which gave a few tips on using Test::Unit to, as the title suggests, test your views.

While, I’m not going to rewrite everything that Jamis wrote, I’d like to show you how to test these views with RSpec. (you might take a moment to quickly read his post…)

In this example, I’m going to show you how we’re able to write specs for the following RHTML, which you’ll notice matches the code that he wrote tests for.

  <% if @user.administrator? %>
    Hi <%= @user.name %>! You appear to be an administrator.
    <%= link_to "Click here", admin_url, :id => "admin_link" %>
    to see the admin stuff!
  <% end %> 

Jamis writes, “The only really significant thing you ought to be testing here is that the admin link only shows up for administrators. “

So, let’s do just that, but with RSpec.

I’m not sure how Jamis is handling his view tests, but we’re going to approach our view specs, much like we approach our controller specs, with the use of mocks and stubs, because we really don’t need to spec any of our models at this level in the application.

Tip: Write specifications for your models… in your model specs not in your controller or view specs.

The first thing that we’re going to do is setup a custom spec helper, because for something like an mocked user, will probably get reused in other areas of the user interface. Spec helpers are essentially modules that you can include in your RSpec descriptions (the block that starts with describe) and reuse.

In this spec helper, I’m going to include two methods, to mock the User model and stub out any of the methods that are necessary for spec’n this view.

module MockUserHelper
  def mock_normal_user
    user = mock(User)
    user.stub!(:administrator?).and_return(false)   # <--- NOT an admin
    user.stub!(:name).and_return('David Chelimsky')
    return user
  end

  def mock_admin_user
    user = mock(User)
    user.stub!(:administrator?).and_return(true)    # <--- IS an admin
    user.stub!(:name).and_return('Aslak Hellesoy')
    return user
  end
end

In the mock_normal_user method, we’re constructing a mock object and stubbing out the methods that we see are being called in the RHTML code. In mock_admin_user, we’re basically doing the same thing, but just stubbing the administrator? method to return true for this mock user.

By stubbing these methods, we’ll be able to send a non-ActiveRecord object to the view and have it render without knowing the difference. For example, the if @user.administrator? condition will return true or false, depending on how we stubbed it.

For more information on mocks and stubs, read here.

Now that we have our spec helper, let’s go ahead and dive into a few specifications for the view.

describe "index page" do
  include MockUserHelper

  it "should render an admin link for an admin user" do
    assigns[:user] = mock_admin_user
    render 'index'
    response.should have_tag('a#admin_link')
  end

  it "should not render an admin link for a normal, non-admin user" do
    assigns[:user] = mock_normal_user
    render 'index'
    response.should_not have_tag('a#admin_link')
  end
end  

Please note: This code example is only longer than the one shown by Jamis because he didn’t include how he setup all his user sessions/objects. ;-)

When these specs are run, we can see the following results.

Pretty output courtesy of RSpec + TextMate bundle

Great, we’ve been able to write specifications for our Rails views without a lot of pain. Stay tuned for more posts on this topic as I continue writing about how Designers and Developers can work together, in harmony. (see my last post on this topic)

For more information on adopting RSpec, please visit the RSpec project homepage.

Josh Knowles just mentioned an article written by David Chelminsky, titled, an introduction to RSpec – Part I. In this article, David introduces you to some of the new language that appeared in some of the recent versions of RSpec as well as give you a complete tutorial on building some specs.

Last night, I had the opportunity to sit down with Aslak Hellesøy and David Chelimsky for a few hours and talk about my experiences of using RSpec at PLANET ARGON and how it’s helped us redefine and evolve our process. In particular, how RSpec has helped us reshape our process of gathering user interaction specifications from our Interaction Design team and business rules from our clients.

If you’re in town and are using RSpec… or are thinking about using RSpec… and see these guys… thank them for all the hard work that they’re doing… and of course, if you run into anybody else on the team... do the same. :-)

Aslak Hellesøy and David Chelimsky

Also, by the end of the conference... Graeme and I are hoping to have a small project done to help encourage more adoption of Behavior-Driven Development

I love to look at other peoples code. Initially, that’s what got me excited about Open Source software. Otherwise, I was looking at small snippets on various developer sites and really not getting the complete picture for how everything tied together.

Last night, I finally had a chance to checkout the sample caboose application, which was created as a way for people to get an idea for how some of developers in caboo.se are putting together their applications.

Some things that you might want to check out it’s using…

• RSpec
• RESTful Authentication
• TzTime
• SpiderTest

It’s definitely worth taking 15 or so minutes to check it out and get some fresh ideas.

There are a few things that I’m not quite sure that didn’t quite make sense, so… perhaps I’ll submit a patch. :-)

svn co svn://caboo.se/plugins/court3nay/empty_apps/tags/v_003

Have fun!

I still believe that Behavior-Driven Development is kinkier than Test-Driven Development...