I did learn something neat tho – proxy_options is useful to know about. Thanks!

it "should have an active named_scope on status" do
    Project.active.proxy_options.should == {:conditions => {:status => "active"}, :order => 'created_at DESC'}
 end

I use rspec, but really I think the idea should be the same no matter what library for testing you use.

I agree with you in part and, what I probably forgot to say in my post, it that there are some situation where it actually makes sense to run a database query.

For instance, testing the raw proxy_options can cause a test to fail just because you are not coding the test in the same way you coded the scope.

In the following case, the test will fail even though the query would return the same recordset regardless you are using strings or symbols.

class Foo < ActiveRecord::Base
  named_scope :active, :conditions => { :active => true }
end

test "named_scope :active symbol" do # won't fail
  expected = { :conditions => { :active => true } }
  assert_equal expected, Foo.active.proxy_options
end

test "named_scope :active string" do # will fail
  expected = { :conditions => { "active" => true } }
  assert_equal expected, Foo.active.proxy_options
end

test "named_scope :active replacement" do # will fail
  expected = { :conditions => ['active = ?', true] }
  assert_equal expected, Foo.active.proxy_options
end

test "named_scope :active replacement with table" do # will fail
  expected = { :conditions => ['foos.active = ?', true] }
  assert_equal expected, Foo.active.proxy_options
end

This is probably the main reason why proxy_option might not be a good candidate for tests in some cases.

An other good one is that testing proxy_options doesn’t ensure you are passing invalid SQL statements to the database. This happened to me in some circumstances where I had to deal with SQLite in development mode and PostgreSQL in production or staging environment.

But the following one, IMHO, is probably a good candidate. Generally, I would prefer testing the specific proxy options when I have fair complex named_scopes (assuming you specifically want to use a named scope and not a classic method).

class Foo < ActiveRecord::Base
    named_scope :latest, lambda { |*args| { :limit => (args.shift || nil), :order => "#{self.table_name}.created_at DESC" }}
end

In this case, you might want to setup a test to stress the different behaviors and eventually an other one to test the effective result of the query.

Many thanks for your comment. It gave me the opportunity to add some more details to the article. :)

At the very least you’d need to ensure that somewhere there was an integration test which properly exercised the method (which happens to be a named scope right now, but may not be in the future) against a set of matching and non-matching records.

I understand the desire to keep tests speedy and decoupled, but I think you’ll struggle to use your final suite of tests to refactor the implementation later on…