+++
date = "2011-10-09"
title = "Testing Rails 3 scopes revisited"
tags = ["Ruby on Rails", "Rails", "rspec", "rails3", "scope", "named_scope"]
slug = "testing-rails-3-scopes-revisited"
+++
In my [previous article][pa] I told you about how I like to tests my scope. There was a fair amount of criticism on that post and after considering it all (and hearing Corey Haines' talk on Arrrrcamp last friday), I'm convinced it's the wrong path.

In essence Rails allows you to create a scope to generate a custom database query for you. Now, if you only test your configuration of Rails (as I did in my previous post), you don't know if that scope works or not. If a piece directly relies on your database, you must test it against your database.

Also, your configuration may be correct, but what happens when you upgrade to a newer version of Rails or PostgreSQL? Does that configuration still work as advertised?

So, this is the proper way of testing your scopes:

``` ruby
class Post < ActiveRecord::Base
  scope :latest, order("created_at DESC")
end

describe Post do
  context 'scopes' do
    before(:all) do
      @first = FactoryGirl.create(:post, :created_at => 1.day.ago)
      @last  = FactoryGirl.create(:post, :created_at => 4.day.ago)
    end

    it "should return posts in the correct order" do
      Post.latest.should == [@first, @last]
    end
  end
end
```

## A note on speed

So, you now have to utilize the whole Rails stack _and_ hit your database to perform this test, which is slow. But then you don't upgrade Rails or your database very often, so you don't have run this spec with every TDD Baby Step you take. (More on that in a later post.)

[pa]: http://ariejan.net/2011/09/25/properly-testing-rails-3-scopes